You are on page 1of 312

Tivoli Application Dependency Discovery Manager

Version 7 Release 2.1

Sensor Reference for Fix Pack 3

Tivoli Application Dependency Discovery Manager


Version 7 Release 2.1

Sensor Reference for Fix Pack 3

Note Before using this information and the product it supports, read the information in Notices on page 293.

Edition notice This edition applies to version 7, release 2, modification 1 of IBM Tivoli Application Dependency Discovery Manager (product number 5724-N55) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright IBM Corporation 2008, 2012. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Contents
Figures . . . . . . . . . . . . . . vii Tables . . . . . . . . . . . . . . . ix About this information . . . . . . . . xi Chapter 1. Overview . . . . . . . . . 1
Sensors that are enabled by default . . . . . . Level 1 discovery profile . . . . . . . . Level 2 discovery profile . . . . . . . . Level 3 discovery profile . . . . . . . . Utilization discovery profile . . . . . . . Sensors that support asynchronous or script-based discovery . . . . . . . . . . . . . . Sensors that support discovery using IBM Tivoli Monitoring . . . . . . . . . . . . . . Sensor setup problems . . . . . . . . . . . . . . . 1 1 2 3 6 Asynchronous and script-based discovery support. . . . . . . . . . . . . . Configuring the sensor . . . . . . . . Using the WebSphere seed sensor for z/OS. . Troubleshooting the sensor . . . . . . . IBM WebSphere eXtreme Scale cache sensor . . Model objects with associated attributes . . . Configuring the sensor . . . . . . . . IBM WebSphere Message Broker sensor . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . IBM WebSphere MQ Server sensor . . . . . Asynchronous and script-based discovery support. . . . . . . . . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . iPlanet server sensor . . . . . . . . . . JBoss server sensor . . . . . . . . . . . Configuring the access list . . . . . . . Troubleshooting the sensor . . . . . . . LDAP sensor . . . . . . . . . . . . . Configuring the access list . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft Cluster sensor . . . . . . . . . Model objects with associated attributes . . . Configuring the access list . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft Exchange Server sensor . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft Exchange 2007 Server sensor . . . . Model objects with associated attributes . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft HyperV sensor . . . . . . . . . Model objects with associated attributes . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft IIS Web server sensor . . . . . . Configuring the access list . . . . . . . Troubleshooting the sensor . . . . . . . NFS sensor . . . . . . . . . . . . . Oracle Application Server sensor . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . SAP CCMS server sensor . . . . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . SAP SLD server sensor . . . . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . SMB server sensor. . . . . . . . . . . Troubleshooting the sensor . . . . . . . SMS server sensor . . . . . . . . . . . Configuring the collation.properties file entries SysImager sensor . . . . . . . . . . . . . . . . . . . . . . 47 48 54 58 64 65 65 65 66 67 67

. 7 . 7 . 9

Chapter 2. Application sensors . . . . 11


Active Directory sensor . . . . . . . . Model objects with associated attributes . . Configuring the sensor . . . . . . . Apache sensor . . . . . . . . . . . Asynchronous and script-based discovery support. . . . . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . Citrix server sensor . . . . . . . . . . Troubleshooting the sensor . . . . . . DNS sensor . . . . . . . . . . . . Troubleshooting the sensor . . . . . . HIS sensor. . . . . . . . . . . . . Model objects with associated attributes . . Configuring the access list . . . . . . Troubleshooting the sensor . . . . . . IBM Cluster Systems Management sensor . . Configuring the sensor . . . . . . . IBM High-Availability Cluster Multi-Processing sensor . . . . . . . . . . . . . . Model objects with associated attributes . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . IBM Lotus Domino server sensor . . . . . Asynchronous and script-based discovery support. . . . . . . . . . . . . Configuring the access list . . . . . . Troubleshooting the sensor . . . . . . IBM Tivoli Monitoring Scope sensor . . . . Model objects with associated attributes . . Configuring the sensor . . . . . . . Uninstalling the sensor . . . . . . . Troubleshooting the sensor . . . . . . IBM WebSphere sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 12 12 13 14 14 15 16 16 16 16 17 21 21 21 21 24 24 26 27 27 29 30 30 31 32 32 38 39 45

. 68 . 69 . 71 . 71 . 71 . 72 . 72 . 73 . 73 . 73 . 74 . 74 . 76 . 76 . 77 . 77 . 78 . 81 . 81 . 86 . 86 . 87 . 88 . 88 . 89 . 89 . 90 . 90 . 91 . 91 . 93 . 94 . 96 . 96 . 98 . 99 . 100 . 101 . 101 . 101 . 102 102 . 103

Copyright IBM Corp. 2008, 2012

iii

Configuring the sensor . . . . . . . Veritas cluster sensor . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . VMware Virtual Center server sensor . . . Model objects with associated attributes . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . WebLogic sensor . . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . WebLogic SSH sensor . . . . . . . . Resources that the sensor discovers . . . Asynchronous and script-based discovery support . . . . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

103 105 106 107 107 108 112 113 114 116 120 123 125

Troubleshooting the sensor . . . IP device sensor . . . . . . . IP interface sensor . . . . . . . Ping sensor . . . . . . . . . Configuring the collation.properties Troubleshooting the sensor . . . Port sensor . . . . . . . . . Session sensor . . . . . . . . Stack Scan sensor . . . . . . . Configuring the sensor . . . . Troubleshooting the sensor . . .

. . . . . . . . . . . . . . . . file entries . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

167 167 168 168 168 169 169 170 170 171 174

Chapter 5. Network sensors . . . . . 179


Overview of SNMP sensors . . . . . . . Calling sequence for SNMP sensors . . . . SNMP MIB walking and debugging SNMP sensors . . . . . . . . . . . . . Maintaining SNMP computer system templates and configuration files . . . . . . . . Alteon port sensor. . . . . . . . . . . Configuring the access list . . . . . . . Alteon SNMP sensor . . . . . . . . . . Configuring the access list . . . . . . . Alteon VLAN sensor . . . . . . . . . . Configuring the access list . . . . . . . BIG-IP port sensor. . . . . . . . . . . Configuring the access list . . . . . . . BIG-IP SNMP sensor . . . . . . . . . . Configuring the access list . . . . . . . BIG-IP VLAN sensor . . . . . . . . . . Configuring the access list . . . . . . . Bridge SNMP sensor . . . . . . . . . . Configuring the access list . . . . . . . Bridge SNMP 2 sensor . . . . . . . . . Configuring the access list . . . . . . . Check Point sensor . . . . . . . . . . Configuring the collation.properties file entries Troubleshooting the sensor . . . . . . . Check Point SNMP sensor . . . . . . . . Configuring the access list . . . . . . . Cisco Adaptive Security Appliance sensor . . . Configuring the sensor . . . . . . . . Cisco Discovery Protocol sensor . . . . . . Configuring the access list . . . . . . . Troubleshooting the sensor . . . . . . . Cisco IOS sensor . . . . . . . . . . . Configuring the sensor . . . . . . . . Cisco port sensor . . . . . . . . . . . Configuring the access list . . . . . . . Cisco VLAN sensor . . . . . . . . . . Configuring the access list . . . . . . . CiscoWorks sensor . . . . . . . . . . Model objects with associated attributes . . Configuring the access list . . . . . . . Entity MIB sensor . . . . . . . . . . . Configuring the access list . . . . . . . Extreme VLAN sensor . . . . . . . . . Configuring the access list . . . . . . . IBM BladeCenter SNMP sensor . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . . 179 . 179 . 180 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 184 184 185 186 186 187 187 187 188 189 189 190 190 192 192 193 193 194 194 194 195 195 196 196 197 197 198 198 199 199 200 200 201 201 202 202 203 203 204 204 206 207

. 127 . 127 . 129

Chapter 3. Database sensors. . . . . 131


IBM DB2 sensor . . . . . . . . . . Asynchronous and script-based discovery support . . . . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . IBM Informix sensor . . . . . . . . . Model objects with associated attributes . Configuring the access list . . . . . . Troubleshooting the sensor . . . . . . Microsoft SQL Server sensor . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . Oracle sensor . . . . . . . . . . . Asynchronous and script-based discovery support . . . . . . . . . . . . Model objects with associated attributes . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . Sybase sensor . . . . . . . . . . . Model objects with associated attributes . Configuring the access list . . . . . . Sybase IQ sensor . . . . . . . . . . Configuring the access list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 . . . . . . . . . . . . . . . . . . . . 132 132 134 136 136 137 138 138 139 141 142 142 143 146 147 147 148 152 152 153

Chapter 4. Generic sensors . . . . . 155


Anchor sensor . . . . . . . . . . . . Configuring the sensor . . . . . . . . Asynchronous discovery sensor . . . . . . Asynchronous discovery ping sensor . . . . Custom application server sensor. . . . . . Custom MIB2 computer system sensor . . . . Generic computer system sensor . . . . . . Generic server sensor. . . . . . . . . . Asynchronous and script-based discovery support . . . . . . . . . . . . . Configuring the collation.properties file entries IBM Tivoli Utilization sensor . . . . . . . Asynchronous and script-based discovery support . . . . . . . . . . . . . Model objects with associated attributes . . Configuring the sensor . . . . . . . . . . . . . . . . 155 155 156 157 157 158 158 159

. 159 160 . 160 . 161 . 162 . 163

iv

Application Dependency Discovery Manager: Sensors

LAN Manager SNMP sensor . . . Configuring the access list . . . NetFlow sensor. . . . . . . . Configuring the sensor . . . . NetScreen SNMP sensor . . . . . Configuring the access list . . . Nokia SNMP sensor . . . . . . Configuring the access list . . . PIX sensor . . . . . . . . . Configuring the access list . . . Configuring the collation.properties SNMP Light sensor . . . . . . Configuring the access list . . . SNMP MIB2 sensor . . . . . . Configuring the access list . . . Troubleshooting the sensor . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . file entries . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

207 207 208 209 211 212 212 213 213 214 214 215 215 216 218 219

Chapter 6. Operating system sensors


HP NonStop computer system sensor . . . Asynchronous discovery support . . . . Troubleshooting the sensor . . . . . . HP-UX computer system sensor . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . IBM AIX computer system sensor . . . . Asynchronous and script-based discovery support . . . . . . . . . . . . Model objects with associated attributes . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . IBM Hardware Management Console sensor . Model objects with associated attributes . Configuring the sensor . . . . . . . IBM Integrated Virtualization Manager sensor Configuring the sensor . . . . . . . IBM i computer system sensor. . . . . . Configuring the access list . . . . . . IPSO computer system sensor . . . . . . Configuring the access list . . . . . . Linux computer system sensor . . . . . Asynchronous and script-based discovery support . . . . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . OpenVMS computer system sensor . . . . Configuring the access list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

221
. . . . . . . . . . . . . . . . . . . . . . . . . . 221 221 222 222 223 224 225 226 226 229 230 230 231 235 236 236 237 238 238 239 239 240 241 242 243 243

Solaris computer system sensor . . . . . Asynchronous and script-based discovery support . . . . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . Solaris zones generic sensor . . . . . . Sun Fire SysControl sensor . . . . . . . Model objects with associated attributes . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . Tru64 computer system sensor. . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . VMware ESX computer system sensor . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . Windows computer system sensor . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . .

. . . . . . . . . . . . . . . . . .

. 243 . . . . . . . . . . . . . . . . . 245 246 247 247 248 249 250 251 251 252 253 253 256 257 260 261 263

Chapter 7. Storage sensors . . . . . 267


Fibre Channel switch sensor . . . . . . . Model objects with associated attributes . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . Host resources sensor . . . . . . . . . Configuring the access list . . . . . . . Host storage sensor . . . . . . . . . . Model objects with associated attributes . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . IBM Tivoli Storage Productivity Center sensor . Model objects with associated attributes . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . Storage sensor . . . . . . . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . Veritas Storage Foundation sensor . . . . . Configuring the collation.properties file entries Troubleshooting the sensor . . . . . . . . . . . . . . . . . . . . . . . . . 267 267 267 268 269 269 270 270 272 274 276 277 282 284 288 288 289 289 290 . 290

Notices . . . . . . . . . . . . . . 293
Trademarks . . . . . . . . . . . . . . 294

Contents

vi

Application Dependency Discovery Manager: Sensors

Figures
1. 2. Calling sequence for SNMP Light sensor and SNMP MIB2 sensor . . . . . . . . . 180 Calling sequence for SNMP sensors, starting after the SNMP Light sensor or the SNMP MIB2 sensor is called . . . . . . . . . 180

Copyright IBM Corp. 2008, 2012

vii

viii

Application Dependency Discovery Manager: Sensors

Tables
1. 2. 3. 4. Sensors that are enabled by default 1 discovery . . . . . . . . Sensors that are enabled by default 2 discovery . . . . . . . . Sensors that are enabled by default 3 discovery . . . . . . . . Sensors that are enabled by default utilization discovery . . . . . for a . . for a . . for a . . for a . . Level . . . 1 Level . . . 2 Level . . . 3 . . . 6 5. 6. 7. 8. 9. 10. Sensors that support asynchronous or script-based discovery . . . . . . . . . 7 Sensors that support discovery using IBM Tivoli Monitoring . . . . . . . . . . . . . 8 Required WebLogic JAR files . . . . . . 116 Configuration parameters . . . . . . . 164 Foundry OID mapping example . . . . . 181 Level 2 bridge topology data . . . . . . 191

Copyright IBM Corp. 2008, 2012

ix

Application Dependency Discovery Manager: Sensors

About this information


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

Copyright IBM Corp. 2008, 2012

xi

xii

Application Dependency Discovery Manager: Sensors

Chapter 1. Overview
For each sensor, this reference includes overview information, and if applicable for the respective sensor, also includes configuration and troubleshooting information. For some sensors, information about the attributes that are associated with the model objects is also included. Where attributes are included, the attributes are available in the IBM Tivoli Common Data Model (CDM) but are not necessarily shown in the IBM Tivoli Application Dependency Discovery Manager (TADDM) UI.

Sensors and supported target systems


The document titled Sensors and supported target systems in the TADDM Wiki at http://www.ibm.com/developerworks/wikis/display/tivoliaddm/Home lists the TADDM sensors and the supported versions of target systems that they can discover.

Discovery process overview


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

Late-breaking updates
For late-breaking updates about TADDM 7.2.1 sensor support issues, see http://www.ibm.com/support/search.wss?q=taddm721relnotes.

Sensors that are enabled by default


These listings indicate which sensors are enabled by default in each of the following four discovery profiles: Level 1, Level 2, Level 3, and utilization.

Level 1 discovery profile


These sensors are enabled by default in a Level 1 discovery profile. Table 1 lists the sensors that are enabled by default for a Level 1 discovery. Sensors are listed in the order in which they are shown in the Discovery Profiles window in the TADDM UI.
Table 1. Sensors that are enabled by default for a Level 1 discovery Sensor Anchor sensor on page 155 SNMP Light sensor on page 215 Stack Scan sensor on page 170 Sensor name that is used in the UI and logs AnchorSensor SnmpLightSensor StackScanSensor

Copyright IBM Corp. 2008, 2012

Level 2 discovery profile


These sensors are enabled by default in a Level 2 discovery profile. Table 2 lists the sensors that are enabled by default for a Level 2 discovery. Sensors are listed in the order in which they are shown in the Discovery Profiles window in the TADDM UI.
Table 2. Sensors that are enabled by default for a Level 2 discovery Sensor Sensor name that is used in the UI and logs

IBM AIX computer system sensor on page AixComputerSystemSensor 225 Alteon port sensor on page 184 Alteon SNMP sensor on page 185 Alteon VLAN sensor on page 186 Anchor sensor on page 155 Asynchronous discovery sensor on page 156 BIG-IP port sensor on page 187 BIG-IP SNMP sensor on page 188 BIG-IP VLAN sensor on page 189 Bridge SNMP 2 sensor on page 192 Bridge SNMP sensor on page 190 Cisco Discovery Protocol sensor on page 196 Check Point SNMP sensor on page 194 Cisco IOS sensor on page 198 Cisco port sensor on page 199 Cisco VLAN sensor on page 200 Custom application server sensor on page 157 Custom MIB2 computer system sensor on page 158 Entity MIB sensor on page 202 Extreme VLAN sensor on page 203 Generic computer system sensor on page 158 Generic server sensor on page 159 IBM Hardware Management Console sensor on page 230 Host resources sensor on page 269 HP-UX computer system sensor on page 222 IBM i computer system sensor on page 237 IP device sensor on page 167 AlteonPortSensor AlteonSnmpSensor AlteonVlanSensor AnchorSensor ASDSensor BigIPPortSensor BigIPSnmpSensor BigIPVlanSensor BridgeSnmpSensor2 BridgeSnmpSensor CdpSensor CheckpointSnmpSensor CiscoIOSSensor CiscoPortSensor CiscoVlanSensor CustomAppServerSensor CustomMib2ComputerSystemSensor EntityMIBSensor ExtremeVlanSensor GenericComputerSystemSensor GenericServerSensor HmcSensor HostResourcesSensor HpUxComputerSystemSensor I5OSComputerSystemSensor IpDeviceSensor

Application Dependency Discovery Manager: Sensors

Table 2. Sensors that are enabled by default for a Level 2 discovery (continued) Sensor Sensor name that is used in the UI and logs

IPSO computer system sensor on page 238 IPSOComputerSystemSensor IBM Integrated Virtualization Manager sensor on page 236 LAN Manager SNMP sensor on page 207 Linux computer system sensor on page 239 NetScreen SNMP sensor on page 211 Nokia SNMP sensor on page 212 OpenVMS computer system sensor on page 243 Ping sensor on page 168 Port sensor on page 169 Session sensor on page 170 SNMP MIB2 sensor on page 216 Solaris computer system sensor on page 243 Sun Fire SysControl sensor on page 248 Tru64 computer system sensor on page 251 VMware ESX computer system sensor on page 253 IvmSensor LanManagerSnmpSensor LinuxComputerSystemSensor NetscreenSnmpSensor NokiaSnmpSensor OpenVmsComputerSystemSensor PingSensor PortSensor SessionSensor SnmpMib2Sensor SunSparcComputerSystemSensor SysControlSensor Tru64ComputerSystemSensor VmwareComputerSystemSensor

Windows computer system sensor on page WindowsComputerSystemSensor 260 Solaris zones generic sensor on page 247 ZonesGenericSensor

Level 3 discovery profile


These sensors are enabled by default in a Level 3 discovery profile. Table 3 lists the sensors that are enabled by default for a Level 3 discovery. Sensors are listed in the order in which they are shown in the Discovery Profiles window in the TADDM UI.
Table 3. Sensors that are enabled by default for a Level 3 discovery Sensor Active Directory sensor on page 11 Sensor name that is used in the UI and logs ActiveDirectorySensor

IBM AIX computer system sensor on page AixComputerSystemSensor 225 Alteon port sensor on page 184 Alteon SNMP sensor on page 185 Alteon VLAN sensor on page 186 Anchor sensor on page 155 Apache sensor on page 12 AlteonPortSensor AlteonSnmpSensor AlteonVlanSensor AnchorSensor ApacheServerSensor
Chapter 1. Overview

Table 3. Sensors that are enabled by default for a Level 3 discovery (continued) Sensor Asynchronous discovery sensor on page 156 BIG-IP port sensor on page 187 BIG-IP SNMP sensor on page 188 BIG-IP VLAN sensor on page 189 Bridge SNMP 2 sensor on page 192 Bridge SNMP sensor on page 190 SAP CCMS server sensor on page 96 Cisco Discovery Protocol sensor on page 196 Check Point sensor on page 193 Check Point SNMP sensor on page 194 Cisco IOS sensor on page 198 Cisco port sensor on page 199 Cisco VLAN sensor on page 200 CiscoWorks sensor on page 201 Sensor name that is used in the UI and logs ASDSensor BigIPPortSensor BigIPSnmpSensor BigIPVlanSensor BridgeSnmpSensor2 BridgeSnmpSensor CCMSServerSensor CdpSensor CheckpointSensor CheckpointSnmpSensor CiscoIOSSensor CiscoPortSensor CiscoVlanSensor v CiscoWorks405FileUDS v CiscoWorks405UDS v CiscoWorksFileUDS v CiscoWorksSensor v CiscoWorksUDS Citrix server sensor on page 15 Custom application server sensor on page 157 Custom MIB2 computer system sensor on page 158 IBM DB2 sensor on page 131 CitrixServerSensor CustomAppServerSensor CustomMib2ComputerSystemSensor v Db2Sensor v Db2WindowsSensor DNS sensor on page 16 IBM Lotus Domino server sensor on page 27 DnsSensor v DominoDomainSensor v DominoServerDetailSensor v DominoInitialSensor Entity MIB sensor on page 202 Microsoft Exchange 2007 Server sensor on page 81 EntityMIBSensor Exchange2007Sensor

Microsoft Exchange Server sensor on page ExchangeServerSensor 77 Extreme VLAN sensor on page 203 Generic computer system sensor on page 158 Generic server sensor on page 159 IBM High-Availability Cluster Multi-Processing sensor on page 24 ExtremeVlanSensor GenericComputerSystemSensor GenericServerSensor HACMPSensor

Application Dependency Discovery Manager: Sensors

Table 3. Sensors that are enabled by default for a Level 3 discovery (continued) Sensor IBM Hardware Management Console sensor on page 230 Host resources sensor on page 269 HP-UX computer system sensor on page 222 IBM i computer system sensor on page 237 Microsoft IIS Web server sensor on page 89 IBM Informix sensor on page 136 IP device sensor on page 167 iPlanet server sensor on page 71 Sensor name that is used in the UI and logs HmcSensor HostResourcesSensor HpUxComputerSystemSensor I5OSComputerSystemSensor IISWebServiceSensor Informix IpDeviceSensor IPlanetServerSensor

IPSO computer system sensor on page 238 IPSOComputerSystemSensor IBM Integrated Virtualization Manager sensor on page 236 JBoss server sensor on page 71 LAN Manager SNMP sensor on page 207 LDAP sensor on page 73 Linux computer system sensor on page 239 Microsoft HyperV sensor on page 87 IBM WebSphere MQ Server sensor on page 67 Microsoft Cluster sensor on page 74 NetScreen SNMP sensor on page 211 NFS sensor on page 91 Nokia SNMP sensor on page 212 OpenVMS computer system sensor on page 243 Oracle Application Server sensor on page 91 Oracle sensor on page 142 Ping sensor on page 168 PIX sensor on page 213 Port sensor on page 169 Session sensor on page 170 SAP SLD server sensor on page 99 SMB server sensor on page 101 SMS server sensor on page 102 SNMP MIB2 sensor on page 216 Microsoft SQL Server sensor on page 138 IvmSensor JBoss4xSensor LanManagerSnmpSensor LdapSensor LinuxComputerSystemSensor Microsoft HyperV Sensor MQServerSensor MSClusterSensor NetscreenSnmpSensor NFSServerSensor NokiaSnmpSensor OpenVmsComputerSystemSensor v OracleAppOpmnSensor v OracleAppSensor OracleSensor PingSensor PixSensor PortSensor SessionSensor SLDServerSensor SMBServerSensor SMSServerSensor SnmpMib2Sensor SqlServerSensor

Chapter 1. Overview

Table 3. Sensors that are enabled by default for a Level 3 discovery (continued) Sensor Storage sensor on page 288 Solaris computer system sensor on page 243 Sybase IQ sensor on page 152 Sybase sensor on page 147 Sun Fire SysControl sensor on page 248 IBM Tivoli Storage Productivity Center sensor on page 276 Tru64 computer system sensor on page 251 Veritas cluster sensor on page 105 Sensor name that is used in the UI and logs StorageSensor SunSparcComputerSystemSensor SybaseIQSensor SybaseSensor SysControlSensor TPCStorageSensor Tru64ComputerSystemSensor VeritasClusterSensor

Veritas Storage Foundation sensor on page VeritasStorageSensor 289 VMware Virtual Center server sensor on page 107 VMware ESX computer system sensor on page 253 WebLogic SSH sensor on page 123 VirtualCenterSensor VmwareComputerSystemSensor v WeblogicLauncherSensor v WeblogicApplicationSensor v WeblogicDomainSensor v WeblogicServerSensor IBM WebSphere sensor on page 45 v WebSphereCellSensor v WebSphereNodeSensor v WebSphereVersionSensor Windows computer system sensor on page WindowsComputerSystemSensor 260 Solaris zones generic sensor on page 247 ZonesGenericSensor

Utilization discovery profile


These sensors are enabled by default in a Utilization discovery profile. Table 4 lists the sensors that are enabled by default for a utilization discovery. Sensors are listed in the order in which they are shown in the Discovery Profiles window in the TADDM UI.
Table 4. Sensors that are enabled by default for a utilization discovery Sensor Anchor sensor on page 155 IBM Tivoli Utilization sensor on page 160 Ping sensor on page 168 Port sensor on page 169 Session sensor on page 170 Sensor name that is used in the UI and logs AnchorSensor OperatingSystemUtilizationSensor PingSensor PortSensor SessionSensor

Application Dependency Discovery Manager: Sensors

Sensors that support asynchronous or script-based discovery


These sensors support asynchronous or script-based discovery. The Asynchronous discovery sensor on page 156 is required for asynchronous discovery. Table 5 lists the sensors that support asynchronous or script-based discovery. Notes: 1. Asynchronous and script-based discovery is supported only if the target computer system is running the AIX, Linux (on x86 systems only), or Solaris operating system. 2. If the target computer system is running the Solaris operating system, script-based discovery might not work if SunSSH 1.0 is used.
Table 5. Sensors that support asynchronous or script-based discovery Sensor Sensor name that is used in the UI and logs

IBM AIX computer system sensor on page AixComputerSystemSensor 225 Apache sensor on page 12 IBM DB2 sensor on page 131 IBM Lotus Domino server sensor on page 27 Generic server sensor on page 159 Linux computer system sensor on page 239 IBM WebSphere MQ Server sensor on page 67 IBM Tivoli Utilization sensor on page 160 Oracle sensor on page 142 Solaris computer system sensor on page 243 WebLogic SSH sensor on page 123 IBM WebSphere sensor on page 45 ApacheServerSensor Db2Sensor DominoInitialSensor GenericServerSensor LinuxComputerSystemSensor MQServerSensor OperatingSystemUtilizationSensor OracleSensor SunSparcComputerSystemSensor WeblogicLauncherSensor WebSphereVersionSensor

Sensors that support discovery using IBM Tivoli Monitoring


These sensors support discovery using IBM Tivoli Monitoring. The IBM Tivoli Monitoring Scope sensor on page 31 is required for discovery using IBM Tivoli Monitoring. This sensor must be run at least once to create the necessary scope sets. The IBM Tivoli Monitoring Scope sensor creates scope sets for all active computer systems in a Tivoli Monitoring environment. After these scope sets are created, you can run Level 2 and Level 3 discovery of those computer systems using a Tivoli

Chapter 1. Overview

Monitoring session, without including the IBM Tivoli Monitoring Scope sensor in the Level 2 and Level 3 discovery profiles. Note: If your IBM Tivoli Monitoring managed computer systems are behind a firewall (are not reachable from TADDM discovery server), you might need to include the IBM Tivoli Monitoring Scope sensor in your profile with startSessionOnly option enabled. For details, see Configuring the discovery profile in IBM Tivoli Monitoring Scope sensor documentation. For Level 2 and Level 3 discovery of the systems that are monitored by IBM Tivoli Monitoring, the following features must be installed on the target system: v On Windows target systems, Microsoft .NET Framework must be installed. See the TADDM Administrator's Guide for information about configuring for discovery of Windows systems. v On Linux and UNIX target systems, uuencode and uudecode commands that are compliant with the Portable Operating System Interface (POSIX) must be installed. On Linux operating systems, these commands are typically included with the sharutils package. On AIX, Solaris, and HP-UX operating systems, these commands are installed by default. Not all sensors in a Level 2 or Level 3 discovery profile support discovery using Tivoli Monitoring. Table 6 lists the sensors that support discovery using Tivoli Monitoring. When a sensor runs within the Tivoli Monitoring session, it uses the Tivoli Monitoring access credentials rather than the access credentials that are configured for the sensor. The Tivoli Monitoring user account must have necessary authorization to access the application that is being discovered. For example, to discover IBM DB2 Universal Database (UDB) servers, the Tivoli Monitoring user account on the target DB2 server must be a member of the DB2 administration group.
Table 6. Sensors that support discovery using IBM Tivoli Monitoring Sensor Sensor name that is used in the UI and logs

IBM AIX computer system sensor on page AixComputerSystemSensor 225 Apache sensor on page 12 IBM DB2 sensor on page 131 Generic server sensor on page 159 Linux computer system sensor on page 239 IBM WebSphere MQ Server sensor on page 67 Storage sensor on page 288 Solaris computer system sensor on page 243 WebLogic SSH sensor on page 123 IBM WebSphere sensor on page 45 ApacheServerSensor Db2Sensor GenericServerSensor LinuxComputerSystemSensor MQServerSensor StorageSensor SunSparcComputerSystemSensor WeblogicLauncherSensor WebSphereVersionSensor

Windows computer system sensor on page WindowsComputerSystemSensor 260

Application Dependency Discovery Manager: Sensors

Sensor setup problems


This information covers common problems that occur with sensor setup in the IBM Tivoli Application Dependency Discovery Manager (TADDM).

A Linux, Solaris, AIX, or Linux on System z operating system cannot be discovered


Problem A Linux, Solaris, AIX, or Linux on System z operating system cannot be discovered. Solution Ensure 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 the hosts. To verify that the login and password or the key and passphrase work properly, enter the ssh command from the command prompt on the computer where the TADDM server is installed. v Install the LiSt Open Files (lsof) program on all host computers according to the requirements in lsof requirements in the TADDM Wiki at http://www.ibm.com/developerworks/wikis/display/tivoliaddm/ Home.

On Linux, Solaris, AIX, and Linux on System z operating systems, discovery never ends
Problem On a Linux, Solaris, AIX, or Linux on System z operating system, discovery never ends. Running the ps -ef command shows instances of the stop-local-anchor.sh process that remain for more than 5 minutes. Solution Access to the sudo command must be configured so that the TADDM user, which is the user that starts the TADDM server, can run sudo commands without having the password prompt displayed. To configure the sudo access in this way, complete the following steps: 1. Login to the TADDM server as the root user. 2. Enter the visudo command. 3. Type the following line in the /etc/sudoers file, where TADDM_USER is the user that starts the TADDM server:
<TADDM_USER> ALL=NOPASSWD:ALL

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

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

Chapter 1. Overview

A discovery of application servers that are running on the Solaris 10 operating system returns incorrect port numbers
Problem Incorrect port numbers are returned when you run a discovery of application servers that are running on the Solaris 10 operating system. Solution Ensure that lsof 4.77, or later, is installed on every system that is running on the Solaris 10 operating system. Versions of lsof prior to 4.77 do not support Solaris 10 6/06 or later. Additionally, there are two version of lsof 4.77. One is for the pre 6/06 Solaris 10 release, and the other is for the 6/06 Solaris 10 release, and later versions. Make sure that you install the version of lsof 4.77 that matches the version of the Solaris 10 Operating System that is installed.

10

Application Dependency Discovery Manager: Sensors

Chapter 2. Application sensors


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

Active Directory sensor


The 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 this command requires elevated security privileges. To verify that the discovery account has 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 attributes


The Active Directory sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about Microsoft Active Directory servers in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. sys.ActiveDirectory v Host v InitRecvTimeout v v v v v v v MaxConnIdleTime MaxConnections MaxDatagramRecv MaxNotificationPerConn MaxPageSize MaxPoolThreads MaxQueryDuration

v MaxReceiveBuffer v MaxResultSetSize v v v v
Copyright IBM Corp. 2008, 2012

MaxTempTableSize MaxValRange NamingContexts Name

11

v v v v

RootDomain SchemaVersion ServiceXML WorkingDirectory

sys.ServiceAccessPoint v ContextIp v BindAddress v Name v ProductName v ProductVersion v VendorName sys.NamingContext v Index v Value

Configuring the sensor


Before 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, and the 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, you can create a custom profile and enable the Active Directory sensor and the Windows computer system sensor from the new profile.

Apache sensor
The Apache sensor discovers Apache Web servers.

Sensor name that is used in the GUI and logs


ApacheServerSensor

Prerequisites
The TADDM service account requires: v Execute permissions on the httpd binary file v Read access to the httpd.conf file

Limitations
The Apache sensor cannot discover the Apache server if the Apache server instance is configured or started in such a way that it rewrites its command line (for

12

Application Dependency Discovery Manager: Sensors

example, rewrites the argv array), causing the Apache server instance to show in a process listing as httpd, without any path or command-line options.

Model objects created


The sensor creates the following model objects: v app.AppConfig v app.CertificateFile v app.ConfigFile v app.PrivateKeyFile v v v v v v app.web.ServerAlias app.web.apache.ApacheGlobalSSLSettings app.web.apache.ApacheModule app.web.apache.ApacheSSLSettings app.web.apache.ApacheServer app.web.apache.ApacheVirtualHost

v app.web.apache.ApacheWebContainer v app.web.ibm.IBMHTTPServer v app.web.oracleapp.OracleAppHTTPServer v app.web.WebConnection v app.web.WebVirtualHostConfigDirective

Asynchronous and script-based discovery support


The Apache sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. See the TADDM Administrator's Guide for information about configuring for script-based discovery.

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 for nonscript-based discovery.

Limitations
Some function that is provided by the Apache sensor during a nonscript-based discovery 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 modified v Owner v Group v Permissions
Chapter 2. Application sensors

13

Only running applications are discovered.

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. This sensor can be run using the ComputerSystem access credentials used to discover 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=false The sensor discovers Apache Web servers and assigns the same name instead of reporting one for each Web server host name. When this property is set to true, the display name for the ApacheServer object is set to: HOSTNAME:LISTENINGIP:PORT The default value of this property is false. You must manually delete the HOSTNAME:PORT instances. com.collation.discover.agent.ApacheServerAgent.CmdPrefix Adds a command or script that must be run before the httpd -V command. This property can be configured for the operating system name, IP address or 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 sensor


This topic describes common problems that occur with the Apache sensor and presents solutions for those problems.

Discovery error with cannot execute httpd


Problem A discovery error states cannot execute httpd, but the TADDM service account can run the httpd process manually. The session sensor tries each appropriate access list credential until one works. When one access list credential works, the session sensor stops trying. Therefore, the first access list credential that works must be able to run the httpd process. Solution Try using scope restrictions with a reordered access list to force the correct account to be used to discover the Apache server.

14

Application Dependency Discovery Manager: Sensors

Apache sensor fails with error CTJTD0072E


Problem The Apache sensor uses the httpd -V command to get the root directory, configuration file, and other information related to the Apache server. If the httpd -V command fails, the sensor also fails. Solution Use the com.collation.discover.agent.ApacheServerAgent.CmdPrefix property to specify a command to run before the httpd -V command is run.

Many fields in the Details panel are empty


Problem A number of fields in the Details panel are empty. Solution The service account cannot read the http.conf file. Make the http.conf file publicly readable, or add the service account to a group that has read access to the http.conf file.

Citrix server sensor


The Citrix server sensor discovers a Citrix Presentation Server or XenApp server.

Sensor name that is used in the GUI and logs


CitrixServerSensor

Security issues
The discovery user must have read permissions (defined in the Citrix Product console) for the Citrix configuration. To discover the Citrix Presentation Server configuration, you must have permission to query the Citrix WMI Provider. This provider must be running in order to be discovered. The Citrix WMI Provider is on your discovered system where the Citrix Presentation Server is installed. It is a part of the Citrix product. To grant this permission, complete the following steps: 1. 2. 3. 4. Log in to the Management Console for Metaframe Presentation Server. From the menu, select Actions > Permissions. Edit the user and group permissions. Ensure that the View farm management permission is granted. This permission is the minimal permission that must be granted to query the Citrix WMI provider. a. Select a user or group. b. Click Edit c. Select the appropriate permission: v View only: works for the Citrix sensor v Full administration: works for the Citrix sensor v Custom: the administrator can define their own access level

Chapter 2. Application sensors

15

Troubleshooting the sensor


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

The Citrix sensor runs slowly


Problem The Citrix sensor runs slowly on systems overloaded with many published Citrix applications. (WMI queries take a long time) Solution Increase the sensor timeout by setting the following property in the collation.properties file: com.collation.discover.agent.CitrixServerAgent.sessiontimeout=300000

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

Sensor name that is used in the GUI and logs


DnsSensor

Model objects created


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

Troubleshooting the sensor


This topic describes common problems that occur with the DNS sensor and presents solutions for those problems.

Sensor fails to discover a DNS server


Problem The sensor is unable to discover a running DNS server. Solution If the sensor fails to discover a DNS server, verify that the DNS server can resolve IP address 127.0.0.1. The DNS sensor requires the DNS server to resolve 127.0.0.1 and, if the DNS server does not return a value, the sensor fails to recognize the particular DNS server.

HIS sensor
The HIS sensor discovers a Microsoft Host Integration Server.

Sensor name that is used in the GUI and logs


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.

16

Application Dependency Discovery Manager: Sensors

v Using the TADDM Windows Management Instrumentation (WMI) provider, WMI read access to the root/microsoftHis namespace must be granted. If the discovery of the Windows Computer System succeeded, this WMI read access is granted by default. Administrative-level access is preferable.

Model objects with associated attributes


The HIS sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about Microsoft Host Integration Server resources in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. app.his.HISDomain v APPCModes v AuditLevel v BroadcastMeanTime v v v v v v BroadcastProtocolIpxSpx BroadcastProtocolNamedPipes BroadcastProtocolTcpIp ClientBackupDomainNames ClientBackupSponsorNames ClientDomainBackupType

v ConfigServer v DisplayName v DisplayVerbConnection v DomainName v EventLogServerName v NetViewConnection v v v v PopupServerName RTMEndOfSession RTMOverflow RTMThreshold

v RTMTimerUntil v Security3270 v v v v SecurityAPPC SecurityLUA Servers Status

app.his.HostIntegrationServer v DisplayName v v v v v v Domain LinkServices Name ProductName ProductVersion ServerRole


Chapter 2. Application sensors

17

v Services v TransportString v VendorName app.his.IPDLCService v BackupNetworkNameServers v CMDMaxRetry v CPName v DeviceDriver v DisplayName v v v v v v DllName IsRemotable LENNode LocalAddressAdapter LocalAddressIP MaxActivationAttempts

v MaxBTUReceive v MaxBTUSend v Name v Network v NodeID v Parent v PrimaryNetworkNameServer v ReceiveAckTimeout v ResolvedIP v UseDynamicPUDefinition app.his.APPCMode v v v v v AllowLZandRLE AutoActivate DisplayName EndPointOnly IsPriority

v MaxReceiveCompression v MaxSendCompression v v v v v v MinimumContentionWinnerLimit Name Parent PartnerMinimumContentionWinnerLimit ReceivePacing ReceiveRuSize

v SessionLimit v TransmitPacing v TransmitRuSize app.his.HISConnection v Activation

18

Application Dependency Discovery Manager: Sensors

v v v v v v v v v v v v v v v v v v

AllowIncoming BlockId CompressionLevel DisplayName DynamicLuDef LUs LinkService Name NodeId Parent PartnerConnectionName PeerRole RemoteBlockId RemoteControlPoint RemoteEnd RemoteNetName RemoteNodeId RetryDelay

v RetryLimit v XIDFormat app.his.HISLUA v Compression v DisplayName v HighPriorityMode v Name v Number v Parent v Protocol v UserWksSecure app.his.HISLUDisplay v AssociatedLU v Compression v DisplayModel v v v v v v DisplayModelOverride DisplayName HISService Name Number Parent

v Protocol v UserWksSecure app.his.HISLUPrint v AssociatedLU v Compression


Chapter 2. Application sensors

19

v v v v v

HISService Name Number Parent Protocol

v UserWksSecure app.his.PrintService v Account v ActivationRetryInterval v v v v v v ActivationRetryLimit AlwaysDoNL CanBePaused CanBeStopped DelayPrintStart Description

v DesktopInteract v DisplayName v DoAllFF v ErrorControl v ExitCode v FlushFinalFF v IgnoreCharsUnder3F v Name v NoEventLogOnSkippingTransparentSection v NoSpaceAfterFF v OperatingState v Parent v v v v v PathName Server ServiceName ServiceSpecificCode ServiceType

v SoftwareVersion v StartMode v Started v UseFixedTabs v UseProportionalFontChange app.his.SNAService v ControlPoint v v v v v HISConnections Name NetworkName Parent Server

20

Application Dependency Discovery Manager: Sensors

Configuring the access list


This topic describes the access details that you require, depending on your configuration. There are no access requirements for this sensor. This sensor can be run using the ComputerSystem access credentials that are used to discover the client.

Troubleshooting the sensor


This topic describes common problems that occur with the HIS sensor and presents solutions for those problems.

WMI service fails on a target during discovery


Problem The Windows Management Instrumentation (WMI) service fails on a target system during discovery. Solution Ensure that all WMI-related fixes, including fix KB933061, are applied on the target system. If the problem persists, run the WMI diagnostic tools from Microsoft.

IBM Cluster Systems Management sensor


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

Sensor name that is used in the GUI and logs


CSMServerSensor and CSMNodeSensor

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

Model objects created


The sensor creates the following model objects: v sys.hpc.cm.ConfigurationManagementCluster v v v v sys.hpc.cm.ConfigurationManagementNode sys.hpc.cm.ConfigurationMangementNodeGroup sys.hpc.cm.ConfigurationManagementClusterConfigFile sys.hpc.CSMNode

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the discovery profile


This 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.
Chapter 2. Application sensors

21

2. Set the following required attributes: masterServerNames The IP addresses or host names of CSM master nodes. This property must be set to start the CSM server sensor. 3. If appropriate, set the following parameters or accept the default values. lsNodeCommand The command used to determine CSM nodes. The default value is lsnode. nodeGrpCommand The command used to determine CSM nodes in the group. The default value is nodegrp. nodeGrpCommandDelimiter The delimiter between nodes in the nodeGrpCommand. The default value is ",". CFMDirectoryLocation The location of the CFM root directory. The default is /cfmroot. CFMDiscoveryMode The depth of file capture of the files and scripts in the CSM configuration 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. CFMDiscoveryPattern The file name pattern for files under the CFM root directory. The default value is "*". preRebootScriptsLocation The location of the scripts that are run before reboot. The default value is /csminstall/csm/scripts/installprereboot/. preRebootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ installprereboot/ directory. The default value is "*". postRebootScriptsLocation The location of the scripts that are run after reboot. The default value is /csminstall/csm/scripts/installpostreboot/. postRebootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ installpostreboot/ directory. The default value is "*". osUpgradePreRebootScriptsLocation The location of the scripts that are run after the OS is upgraded, but before reboot. The default value is /csminstall/csm/scripts/ osupgradeprerboot/. osUpgradePreRebootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ osupgradeprereboot/ directory.

22

Application Dependency Discovery Manager: Sensors

The default value is "*". osUpgradePostRebootScriptsLocation The location of the scripts that are run after the OS is upgraded, and after reboot. The default value is /csminstall/csm/scripts/ osupgreadepostreboot/. osUpgradePostRebootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ osupgradepostreboot/ directory. The default value is "*". disklessBootScriptsLocation The location of the boot scripts for diskless nodes. The default value is /csminstall/csm/scripts/disklessboot/. disklessBootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ disklessboot/ directory. The default value is "*". disklessPreBuildScriptsLocation The location of the pre-build scripts that are run for diskless nodes. The default value is /csminstall/csm/scripts/disklessprebuild/. disklessPreBuildScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ disklessprebuild/ directory. The default value is "*". dataScriptsLocation The location of any additional scripts or data files referenced by the scripts. The default value is /csminstall/csm/scripts/data/. dataScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ data/ directory. The default value is "*". updateScriptsLocation The location of the scripts that are run after any CSM updates have completed. The default value is /csminstall/csm/scripts/update/. updateScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ update/ directory. The default value is "*". nodesScope The scope of the IP addresses to which the CSM node sensors are restricted. doPingNodes Specifies whether ping sensors are run against discovered CSM nodes.

Chapter 2. Application sensors

23

There are no specific sensor setup requirements associated with the CSMNodeSensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. CSMServerSensor uses CSM Server access entry. If this access entry is not available, the sensor uses ComputerSystem access entry to access the CSM server. CSMNodeSensor uses ComputerSystem access entry to access CSM nodes.

IBM High-Availability Cluster Multi-Processing sensor


The IBM High-Availability Cluster Multi-Processing (HACMP) sensor discovers HACMP clusters and associated components. The sensor discovers information about the cluster, nodes, resource groups, local resource groups, application resources, cluster manager, service IP label, shared file system, node network addresses, and site information.

Sensor name that is used in the GUI and logs


HACMPSensor

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

Security issues
Privileges to execute the following commands on the discovered systems are required: 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.

Model objects with associated attributes


The IBM HACMP sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about configuration items in the IBM HACMP environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. HACMPAppResource v AppServer v LocalAppResources v Name v Parent

24

Application Dependency Discovery Manager: Sensors

HACMPCluster v ClusterID v ComputerSystems v ConnAuthMode v HeartbeatNetworks v v v v v v v MessageAuthMode MessageEncryption Nodes ResourceGroups State Substate UsePersistentLabel

HACMPClusterHeartbeatNetwork v Name v Netmask v NetworkElements v Parent v PrefixLength v Type HACMPClusterHeartbeatNetworkElement v L2Interface v v v v Name NetworkAddress Parent StorageVolume

v Type HACMPClusterManager v CurrentState v HacmpNode HACMPLocalAppResource v Node v Parent v StartScript v StopScript HACMPLocalResourceGroup v LocalState v Node v Parent HACMPNode v ClusterManager v LocalAppResources v LocalResourceGroups v Name v NetworkElements
Chapter 2. Application sensors

25

v v v v

Parent SiteInfo State System

HACMPResourceGroup v AppResources v FallbackPolicy v FalloverPolicy v FileSystems v v v v v v GlobalState LocalResourceGroups Nodes Parent PrimaryNode ServiceIpLabels

v SitePolicy v StartupPolicy v StorageVolumes ServiceIPLabel v IpAddress v Name v Parent SiteInfo v Name

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


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


This topic lists the collation.properties file entries that the IBM HACMP sensor uses. 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 sensor starts. For example,
com.collation.platform.os.UnixOs.forcedServerList=vxconfigd;clstrmgr

26

Application Dependency Discovery Manager: Sensors

Troubleshooting the sensor


This topic describes common problems that occur with the IBM HACMP sensor and presents solutions for those problems.

HACMP cluster is duplicated


Problem A 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. Solution To resolve a situation where a HACMP cluster has been duplicated, using the Data Management Portal, delete the copy of the cluster that has the old cluster name.

Incorrect HACMP version returned


Problem When discovering a HACMP cluster with the IBM HACMP sensor, the product version of the HACMP cluster might be incorrectly discovered as "0". Solution Because of an issue in the HACMP, the incorrect cluster version is sometimes returned. To manually check the cluster version, run the following command on one of the HACMP cluster nodes:
ssrc -ls clstrmgrES

In the command output, check the version of the HACMP cluster, for example
local node vrmf is 0

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

IBM Lotus Domino server sensor


The IBM Lotus Domino server sensor discovers Lotus Domino servers.

Sensor name that is used in the GUI and logs


DominoDomainSensor, DominoServerDetailSensor, and DominoInitialSensor

Prerequisites
On the Lotus Domino system, a user account must be configured with the correct access to the resources being discovered. Ensure that the following requirements are 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.2.0/
Chapter 2. Application sensors

27

plugin.xml file. You can append the port number of the Domino IIOP server to the server name. Adding the port number is optional. Typically, the default port number is 63148 for Domino Internet Inter-ORB Protocol (DIIOP). If anonymous access 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 the correct 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 the osgi/plugins/ com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.2.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. The TrustedCerts.class file is located in the domino data folder/domino/java folder. v Issue the show task command in the Domino console to determine if the DIIOP task is running. v If the DIIOP task is not running, issue the load diiop command using the Domino 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 the changes to take effect.

Model objects created


The sensor creates the following model objects: v app.lotus.AgentManager v app.lotus.AdminProcess v app.lotus.DirectoryAssistance v app.lotus.DirectoryCataloger v v v v app.lotus.DomainCatalog app.lotus.DominoCluster app.lotus.DominoConnection app.lotus.DominoDatabase

28

Application Dependency Discovery Manager: Sensors

v v v v v v v v v v v v v v v v v v

app.lotus.DominoDomain app.lotus.DominoNamingContext app.lotus.DominoReplicas app.lotus.DominoSecurity app.lotus.DominoServer app.lotus.DominoTransactionLogging app.lotus.HTTPFilterSpecialtyServer app.lotus.IIOPConfig app.lotus.IMAPConfig app.lotus.InternetClusterManager app.lotus.LDAPConfig app.lotus.OtherDatabase app.lotus.POPConfig app.lotus.RemoteDebugManager app.lotus.SMTPConfig app.lotus.SpecialityServer app.lotus.WebConfig app.lotus.WebRetriever

Asynchronous and script-based discovery support


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

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. See the TADDM Administrator's Guide for information about configuring for script-based discovery.

Access list configuration requirements


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

Limitations
Most function that is provided by the Lotus Domino server sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. In an asynchronous or script-based discovery, only the Version attribute is supported. Application descriptor discovery is not supported.

Chapter 2. Application sensors

29

Configuring the access list


To 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. The Session sensor creates a session between the TADDM server and the target computer systems before the IBM Lotus Domino server sensor discovery run.

Troubleshooting the sensor


This topic describes common problems that occur with the IBM Lotus Domino server sensor and presents solutions for those problems.

The sensor does not start


Problem If the Domino Internet Inter-ORB Protocol (DIIOP) is not running or the plugin.xml file is not correctly configured, the sensor does not start or it fails. Solution v Check the $COLLATION_HOME/osgi/plugins/ com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.2.0/ plugin.xml file to ensure that it is configured correctly. If you update the plugin.xml file, you must restart the TADDM server for the changes to take 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
Problem For AIX operating systems, if the notes.ini file is not found in the processing environment the sensor does not start. Solution The user ID carrying out the discovery does not have access to the process environment due to security issues. Check the following entry in the collation.properties file:
com.collation.platform.os.command.psEnv.AIX

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

30

Application Dependency Discovery Manager: Sensors

IBM Tivoli Monitoring Scope sensor


Using the credentials for the Tivoli Enterprise Portal Server rather than the credentials for each computer that the portal server monitors, the IBM Tivoli Monitoring Scope sensor discovers configuration items in the IBM Tivoli Monitoring environment. The IBM Tivoli Monitoring Scope sensor provides the following discovery capability: 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 by Tivoli Monitoring. v Creates special scope sets for all Tivoli Monitoring endpoints that it discovers so that all future TADDM Level 2 (and some Level 3) discoveries can be run without needing access credentials for the Tivoli Monitoring endpoints. Also see the TADDM Administrator's Guide for information about configuring for discovery using IBM Tivoli Monitoring.

Sensor name that is used in the GUI and logs


ITMScopeSensor and ITMScopeSensor-x.xx.xxx.xxx.log, where x.xx.xxx.xxx represents the IP address of the discovered system. The IBM Tivoli Monitoring Scope sensor also logs information to local-anchor.hostname.ITMScopeSensor.log, where hostname represents the host name of the TADDM server.

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

Limitations
Discovery using the Tivoli Monitoring Scope sensor causes the following performance impacts in the Tivoli Monitoring environment: v An increase in CPU usage on the Tivoli Enterprise Portal Server and the Tivoli Enterprise Monitoring Server v An increase in network utilization v 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 might also affect the performance of the Tivoli Monitoring functions, depending on the Tivoli Monitoring hardware that is used. The sensor does not discover hosts on a private network that uses network address translation (NAT).

Chapter 2. Application sensors

31

Model objects with associated attributes


The IBM Tivoli Monitoring Scope sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about configuration items in the IBM Tivoli Monitoring environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. net.IpInterface v IpAddress Multiple computer systems, with the following model objects: sys.aix.AixUnitaryComputerSystem sys.hpux.HpUxUnitaryComputerSystem sys.linux.LinuxUnitaryComputerSystem sys.sun.Solaris sys.sun.SunSPARCUnitaryComputerSystem sys.UnitaryComputerSystem sys.windows.WindowsComputerSystem sys.zOS.ZSeriesComputerSystem The following attributes are associated with these model objects: v Fqdn v Ipinterface v Name v OSInstalled v OSRunning v Signature v Type Multiple operating systems, with the following model objects: sys.aix.Aix sys.hpux.HpUx sys.linux.Linux sys.sun.Solaris sys.zOS.Sysplex sys.unix.Unix sys.windows.WindowsOperatingSystem sys.zOS.ZOS The following attributes are associated with these model objects: v Name v ManagedSystemName v OSVersion

Configuring the sensor


Before running a discovery of the IBM Tivoli Monitoring environment, you must configure the IBM Tivoli Monitoring Scope sensor.

32

Application Dependency Discovery Manager: Sensors

Copying necessary files from the Tivoli Enterprise Portal Server to the TADDM server
You must copy some files from the Tivoli Enterprise Portal Server to the TADDM server. In a streaming server deployment, perform these steps on the discovery server, if you are configuring the sensor for the first time. You do not complete this procedure if you already copied the files from the Tivoli Enterprise Portal Server to the TADDM server and you upgraded to version 7.2.1 Fix Pack 1 or later. 1. On the TADDM server, verify that a $COLLATION_HOME/osgi/plugins/ com.ibm.cdb.session.itm_7.2.1.2/lib/itm directory exists. 2. Copy the following files from the Tivoli Enterprise Portal Server into the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.session.itm_7.2.1.2/lib/itm directory on the TADDM server: v browser.jar v v v v v cnp.jar cnp_vbjorball.jar kjrall.jar util.jar 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. Copy the cfwk.zip from the Tivoli Enterprise Portal Server into the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.session.itm_7.2.1.2/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 and group of the previously copied files to the user and group that is used to run the TADDM server:
chown -R taddmuser:taddmuser $COLLATION_HOME/osgi/plugins/com.ibm.cdb.session.itm_7.2.1.2/lib/itm

5. Restart the TADDM server.

Distributing the discovery target support bundle


During the discovery process, the IBM Tivoli Application Dependency Discovery Manager (TADDM) must copy binary file data between itself and the discovery target using IBM Tivoli Monitoring as an intermediary. For Windows discovery targets, the discovery target support enables binary files to be copied from TADDM to the discovery target as part of the discovery process. The discovery target support bundle also provides part of the Windows gateway on the target so that the gateway is available during discovery. This method prevents you from having to deploy a separate Windows discovery gateway within your Tivoli Monitoring environment. The discovery target support bundle is not required on Linux, AIX, Solaris, and HP-UX operating systems. Before the first discovery from TADDM, the discovery target support bundle must be deployed onto each Tivoli Monitoring Windows operating system endpoint. The

Chapter 2. Application sensors

33

bundle has a small footprint and is designed to be non-intrusive and used only during a TADDM discovery. If you are performing a Level 1 discovery, this task is not required. You must distribute the support bundle to the Windows discovery targets through the Tivoli Enterprise Monitoring Server depot. The support bundle must also be loaded into any remote Tivoli Enterprise Monitoring Server depots that exist in your Tivoli Monitoring environment. In addition to deploying the discovery target support bundle, you must ensure that each Tivoli Monitoring endpoint is configured for discovery. For example, each UNIX-based endpoint must have the LiSt Open Files (lsof) program installed. For more information, see the topic Configuring target computer systems in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center. On the TADDM DVD, the support bundle is in the KD7.zip or KD7_621.zip file in the /itm-discovery-support directory. Depending on the version of Tivoli Enterprise Monitoring Server, distribute the appropriate support bundle. For IBM Tivoli Monitoring Version 6.2.1-TIV-ITM-FP0001 or later, distribute the support bundle in KD7_621.zip. For IBM Tivoli Monitoring Version 6.2.2-TIV-ITM-FP0002 or later, distribute the support bundle in the KD7.zip. To distribute the support bundle to the discovery targets, complete the following steps: 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:\TEMP directory 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 the confirmation, 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\072101000 KUICAB023I: Are you sure you want to add the following bundles to the C:\IBM\ITM\CMS\depot\ depot? Type : Product Code : Deployable : Version : Description : Host Type : Host Version : Prerequisites: Component d7 true 072101000 TADDM Discovery through ITM enablement WINNT WINNT

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 number and 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/072101000/ KUICAB023I: Are you sure you want to add the following bundles to the /opt/IBM/ITM/tables/TEMS/depot depot?

34

Application Dependency Discovery Manager: Sensors

Type : Product Code : Deployable : Version : Description : Host Type : Host Version : Prerequisites:

Component d7 true 072101000 TADDM Discovery through ITM enablement WINNT WINNT

KUICAB024I: Enter Y for yes or N for no: y KUICAB020I: Adding bundles to the /opt/IBM/ITM/tables/TEMS/depot depot. The time required to complete this operation depends on 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, use the tacmd listSystems -t NT command. For more information about the tacmd listSystems -t NT command, see tacmd CLI commands at: http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/ com.ibm.itm.doc_6.2.2fp2/tacmd.htm. 4. To distribute the support bundle from the Tivoli Enterprise Monitoring Server to the discovery targets, log in to the Tivoli Enterprise Monitoring Server, and run the tacmd command, as shown in the following sample: 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 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 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 getDeployStatus command. For example:
C:\IBM\ITM\bin>tacmd getdeploystatus -g 121969167781300000018467 Transaction ID : 121969167781300000018467 Command : INSTALL Status : SUCCESS Retries : 0 TEMS Name : HUB_TEMS Target Hostname: Primary:OMPDEV2:NT Platform : WINNT Product : D7 Version : 072101000 Error Message : KDY0028I: Request completed successfully. Deployment request was processed successfully and is now completed.

Installing custom queries on the Tivoli Enterprise Portal Server


For both Level 1 and Level 2 discovery through IBM Tivoli Monitoring, you must install custom queries on the Tivoli Enterprise Portal Server to support the lookup of managed system MAC addresses and agent versions by the IBM Tivoli Monitoring 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 the install_zkd7.sql file.
Chapter 2. Application sensors

35

These queries return the following information: v Version number of the agent on each endpoint v MAC address of each Linux endpoint v Operating system name and version of each endpoint To install the custom queries on the Tivoli Enterprise Monitoring Server, complete the following steps: Installing on Linux operating system: 1. Log in to the Tivoli Enterprise Portal Server, and copy the TEPS_Query.zip file to a local directory. In these instructions, the TEPS_Query.zip file is copied to the /tmp/teps directory and extracted. The install_zkd7.sql and uninstall_zkd7.sql files 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 the TEPS_Query.zip file to a local directory. In these instructions, the TEPS_Query.zip file is copied to the c:\TEMP\TEPS directory and extracted. The install_zkd7.sql and uninstall_zkd7.sql files are then located in the c:\TEMP\TEPS directory. 2. Change to the directory where the Tivoli Enterprise Portal Server is installed:
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 Tivoli Enterprise Portal Server.

Configuring the discovery profile


By default, the IBM Tivoli Monitoring Scope sensor is not enabled. After you enable it, TADDM discovers Tivoli Monitoring endpoints and creates a scope set. The scope set contains the discovered endpoints and uses the default Tivoli Enterprise Portal Server port 1920. However, by default, computer system objects are not created for the Tivoli Monitoring endpoints. If you want to create computer system objects for each discovered endpoint or to use a Tivoli Enterprise Portal Server port other than 1920, create a new Level 1 or Level 2 discovery profile for the IBM Tivoli Monitoring Scope sensor, and customize 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. In the Clone existing profile field, click Level 1 Discovery or Level 2 Discovery, and click OK.

36

Application Dependency Discovery Manager: Sensors

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 Configuration check box. 6. In the Configuration section of the Create Configuration window, to define a set of ports to look for the Tivoli Enterprise Portal Server, click portList. Then double-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. Then double-click the Value field in the row, and type false. The default value for useDefaultPortList is true. If a port list is provided and useDefaultPortList is set to true, port 1920 is added to the list of ports to look for the Tivoli Enterprise Portal Server. 8. To create computer system objects that display in the discovered components tree during a discovery, click discoverITMEndpoints. Then double-click the Value 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. 9. Click OK to return to the Discovery Profiles window. 10. In the Discovery Profiles window, click Save.

Discovering endpoints behind firewalls


The IBM Tivoli Monitoring Scope sensor supports the Tivoli Monitoring endpoints that are behind a firewall.

Procedure
1. Make sure that the scope.properties file is created. 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 by ITM, and runs a session sensor. The sensor uses the ITM session only if it is allowed and preferred for the host. Restriction: The startSessionOnly parameter has a priority over all other configuration options. If enabled, the sensor does not start any other operations.

Configuring the access list


To give the IBM Tivoli Monitoring Scope sensor access to the Tivoli Enterprise Portal Server application, 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 your Tivoli Enterprise Portal Server, or use an existing scope that contains 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 IBM Tivoli Monitoring.

Chapter 2. Application sensors

37

5. 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 the credentials for the computer on which the Tivoli Enterprise Portal Server resides.

Uninstalling the sensor


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

Deleting access list entries


From the Discovery Management Console, delete each IBM Tivoli Monitoring access 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 profiles


From the Discovery Management Console, delete each IBM Tivoli Monitoring discovery 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 Portal Server


To uninstall the IBM Tivoli Monitoring Scope sensor configuration, you must uninstall 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 file in the /itm-discovery-support directory. To uninstall the custom queries on the Tivoli Enterprise Portal Server, complete the following steps: Uninstall on Linux operating system: 1. Log in to the Tivoli Enterprise Portal Server, and copy the TEPS_Query.zip file to a local directory. In these instructions, the TEPS_Query.zip file is copied to the /tmp/teps directory and extracted. The uninstall_zkd7.sql file is then located in the /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:

38

Application Dependency Discovery Manager: Sensors

/opt/IBM/ITM/bin/itmcmd agent start cq

Uninstall on Windows operating system: 1. Log in to the Tivoli Enterprise Portal Server, and copy the TEPS_Query.zip file to a local directory. In these instructions, the TEPS_Query.zip file is copied to the c:\TEMP\TEPS directory and extracted. The uninstall_zkd7.sql file is then located in the c:\TEMP\TEPS directory. 2. Change to the directory where the Tivoli Enterprise Portal Server is installed:
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 Tivoli Enterprise Portal Server.

Removing the discovery target support bundle


To uninstall the IBM Tivoli Monitoring Scope sensor configuration, you must remove the target support bundle on the Tivoli Enterprise Monitoring Server depots. 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 the following sample. Provide the product code (D7) using the -t option, and the managed 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 Server depot, run the tacmd command, as shown in the following sample. Provide the path to the directory where the installable bundles are located, using the -i option.
tacmd removeBundles -i C:\TEMP\KD7\062001000

Deleting the Tivoli Enterprise Portal Server files from the TADDM server
To uninstall the IBM Tivoli Monitoring Scope sensor configuration, you must delete the files that were copied from the Tivoli Enterprise Portal Server to the TADDM server. To delete the files copied from the Tivoli Enterprise Portal Server, complete the following steps: 1. On the TADDM server, delete the $COLLATION_HOME/osgi/plugins/ com.ibm.cdb.session.itm_7.2.1.1/lib/itm directory. 2. Restart the TADDM server.

Troubleshooting the sensor


This topic describes common problems that occur with the IBM Tivoli Monitoring Scope sensor and presents solutions for those problems.
Chapter 2. Application sensors

39

Computer systems that are outside of the defined scope are created
Problem During a discovery, some computer systems that are outside of the defined scope are created. Solution If the discoverITMEndpoints attribute in the discovery profile for this sensor is set to true, the sensor, during a discovery, creates a computer system for each Tivoli Monitoring endpoint that is known to the Tivoli Enterprise Portal Server. This creation occurs even if an endpoint is outside of the initial discovery scope that included the portal server.

Updates made to the generated Tivoli Monitoring scope using the Discovery Management Console are overwritten
Problem Updates that have been made to the generated Tivoli Monitoring scope in the previous discovery using the Discovery Management Console are overwritten. Solution During a Level 1 discovery, a new scope is created based on the name of the Tivoli Enterprise Portal Server. This scope is overwritten the next time that the portal server is discovered during a Level 1 or Level 2 discovery. To change the generated Tivoli Monitoring scope, create a scope with a different name that contains the elements of the generated scope.

In a large Tivoli Monitoring environment, the sensor fails with a timeout error
Problem In a large Tivoli Monitoring environment, the Tivoli Monitoring Scope sensor fails with a timeout error. Solution In the etc/collation.properties file, edit the following property, where value is the number of milliseconds allowed for the sensor to run (for example, 60000 is 1 minute):
com.collation.discover.DefaultAgentTimeout=value

This property is set to a value of 600000, which is 10 minutes by default.

The sensor fails with a timeout error when slow network links or many router hops exist between the target systems and the Tivoli Enterprise Portal Server or TADDM
Problem The Tivoli Monitoring Scope sensor fails with a timeout error. Slow network links or many router hops exist between the target systems and the Tivoli Enterprise Portal Server or TADDM. The environment includes Windows, Linux, and UNIX systems. Solution This problem is caused by TCP buffer settings. Because the buffer sizes are sometimes too small, poor performance occurs with the TADDM sensors and the Tivoli Enterprise Portal Server.

40

Application Dependency Discovery Manager: Sensors

To solve this problem, complete the following steps, depending on the operating system: On AIX systems: 1. Run the following commands:
/usr/sbin/no -o tcp_sendspace=32768 /usr/sbin/no -o tcp_recvspace=32768

2. Restart the TADDM server. On Linux systems: 1. Edit the /etc/sysctl.conf file with the following settings:
# increase TCP maximum buffer size net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # increase Linux autotuning TCP buffer limits # min, default, and maximum number of bytes to use net.ipv4.tcp_rmem = 4096 87380 16777216 net.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

2. Restart the TADDM server.

Error message results from running the tacmd getDeployStatus command after deploying the discovery target support bundle
Problem One or more of the following messages result from running the tacmd getDeployStatus command after deploying the discovery target support bundle: 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 with a return code of for product code d7. The command /opt/IBM/ITM/tmaitm6/aix526/bin/kdy_xa -setCMS d7 produced the following error text: <Variable formatSpec="{4}">stdErr Text</Variable>. The specified return code was received from the two-way translator. v Error Message: KDY1024E: The agent failed to respond to the command C:\itmagent\installITM\Batch\kincli -startagent -akd7 did not start or stop agent. The command returned a failure return code.

Solution These messages do not indicate actual errors, because the discovery target support bundle is not intended to respond to the agent start or stop command. The Tivoli Monitoring cinfo command also does not list the support bundle, because the support bundle is an addition to the existing OS agent. Verify that the discovery target support bundle is correctly installed on the discovery target. From the Tivoli Monitoring directory on the target computer, run the directory command as shown in the following example:
Chapter 2. Application sensors

41

C:\Documents and Settings\Administrator>cd %CANDLEHOME% C:\IBM\ITM>dir taddm Volume in drive C has no label. Volume Serial Number is B81D-9114 Directory of C:\IBM\ITM\taddm 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 06:38 PM <DIR> . 06:38 PM <DIR> .. 06:38 PM 6,656 Base64.exe 06:38 PM 1,960 KD7WINNT.dsc 06:38 PM 1,363 post.bat 06:38 PM 4,280 pre.bat 06:38 PM 249,856 TaddmTool.exe 06:38 PM 474,624 TaddmTool.pdb 06:38 PM 569,344 TaddmWmi.dll 06:38 PM 106,496 TaddmWmi.exe 06:38 PM 1,424 TaddmWmi.mof 06:38 PM 2,968,576 TaddmWmi.pdb 10 File(s) 4,384,579 bytes 2 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 Windows target systems, multiple command windows open on the computer where the Tivoli Enterprise Portal Server is running
Problem When you run the IBM Tivoli Monitoring Scope sensor for a Level 2 discovery on Windows target systems, multiple command windows open on the computer where the Tivoli Enterprise Portal Server is running. Solution The IBM Tivoli Monitoring Windows OS Agent is probably configured to run as a system service, and the option Allow Service to Interact with Desktop 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


Problem During a Level 2 discovery through IBM Tivoli Monitoring, some commands fail on endpoints, which causes multiple KD7* files or session_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 that ended prematurely or a problem with the Tivoli Monitoring agent connection to the Tivoli Enterprise Monitoring Server.

42

Application Dependency Discovery Manager: Sensors

Solution The administrator can remove these files manually at any time that discovery is not running. Removing these files during a discovery can cause discovery to fail.

Trailing white spaces exist in the output from discovery targets


Problem If you create custom server templates that run under the IBM Tivoli Monitoring Scope sensor, trailing white spaces (such as newline characters or carriage returns) might exist in the output from discovery targets. Solution To ensure that custom server templates provide the same output when used with the Tivoli Monitoring Scope sensor, remove white spaces in the server-side logic of the custom server template.

After upgrading IBM Tivoli Monitoring, errors occur during discovery


Problem After upgrading IBM Tivoli Monitoring, errors might occur during discovery for the following reasons: v A result of updates to the Tivoli Monitoring libraries or agent tables v A result of updates to the TADDM discovery logic Solution If the errors result from updates to the Tivoli Monitoring libraries or agent tables, redo the following tasks: v Copying necessary files from the Tivoli Enterprise Portal Server to the TADDM server on page 33 v Installing custom queries on the Tivoli Enterprise Portal Server on page 35 If the errors result from updates to the TADDM discovery logic, redo the following tasks: v Copying necessary files from the Tivoli Enterprise Portal Server to the TADDM server on page 33 v Distributing the discovery target support bundle on page 33 v Installing custom queries on the Tivoli Enterprise Portal Server on page 35 v Configuring the discovery profile on page 36 v Configuring the access list on page 37

Errors occur during discovery of a Tivoli Monitoring 6.2.2 environment


Problem During the discovery of a Tivoli Monitoring Version 6.2.2 environment, the Tivoli 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 system

v CTJTD3000E Starting - An error occurs and the sensor timed out Solution Verify that the Tivoli Enterprise Monitoring Server process on the Tivoli
Chapter 2. Application sensors

43

Monitoring server is running, and if necessary, restart the Tivoli Enterprise Monitoring Server. This process might shut down unexpectedly due to too many proxy requests, which is related to a known problem with Tivoli Monitoring 6.2.2. For more information, see Tivoli Monitoring APAR IZ52960.2.

Tivoli Monitoring scope does not include all endpoints defined on the Tivoli Enterprise Portal Server
Problem The Tivoli Monitoring scope created during a discovery does not include all the endpoints that are defined on the Tivoli Enterprise Portal Server. Solution Inactive endpoints and endpoints for which MAC addresses cannot be resolved are not included in a created scope set.

Targets are discovered by IBM Tivoli Monitoring session but not by SSH or WMI during a Level 2 discovery
Problem When an endpoint is discovered by the IBM Tivoli Monitoring Scope sensor, future Level 2 discoveries use Tivoli Monitoring for discovery by default. A direct connection (SSH or WMI) is not used. This method is used even if the IBM Tivoli Monitoring Scope sensor is not included in the discovery profile. Solution To discover the endpoint through SSH or WMI, define the following property 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 modify properties that affect how TADDM discovers Tivoli Monitoring endpoints.

Too many active report queries on the Tivoli Enterprise Portal Server
Problem The following informational message is generated in the SessionSensor.log file:
KFWITM460E: Too many active report queries from client IPAddress; exceeding limit at number requests.

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

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

44

Application Dependency Discovery Manager: Sensors

IBM WebSphere sensor


The IBM WebSphere sensor discovers IBM WebSphere Application Server node information, cell information, and version information. TADDM captures all the configuration files and configuration information from the WebSphere Network Deployment Manager system. If changes are made to the files on the Deployment Manager System, they might not be the same on the actual distributed node system. This difference can be caused by the time taken to update the file changes on the distributed node system. Therefore, a configuration change that is flagged on a distributed node might not reflect what is actually on the distributed 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 conflict with other TADDM processes.

Sensor name that is used in the GUI and logs


WebSphereCellSensor, WebSphereJDBCDriverSensor, WebSphereNodeSensor, and WebSphereVersionSensor

Prerequisites
For IBM WebSphere Virtual Enterprise discoveries, you must install and run the IBM WebSphere Network Deployment Manager system and IBM WebSphere Virtual Enterprise. Also, at least one dynamic cluster must be defined. For IBM WebSphere JDBC driver discoveries, ensure that the following prerequisites are met: v Java is present in the system path variable. v The user has permission to execute Java. v The user has permission to read the JDBC driver JAR files. For IBM WebSphere JDBC driver discoveries on Oracle databases, you must also ensure that the user has permission to write to the directory containing 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 All active and inactive JDBC connections identified at server scope through JMX are resolved. JDBC connections scoped at cell, node, cluster, or application levels are not resolved. 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, it must be in the discovery scope. If it is not in the discovery scope, the local-anchor log shows the following messages:

Chapter 2. Application sensors

45

2008-05-17 11:52:54,375 [Thread: 0,8495] WARN j2ee.WebSphereAgent [WebSphereAgent.W.7] verifyStandaloneServer() determined cell to be distributed (DISTRIBUTED), terminating discovery 2008-05-17 11:52:54,379 [Thread: 0,8495] WARN j2ee.WebSphereAgent [WebSphereAgent.W.2] Terminating discovery of managed server/nodeagent portfolio_sptfde71-02_1 - discovery will be handled at cell level 2008-05-17 11:52:54,384 [Thread: 0,8495] DEBUG j2ee.WebSphereAgent discover() finalizing 2008-05-17 11:52:54,384 [Thread: 0,8495] DEBUG cdb.AnchorServer[0] server(0) sendMessage to:127.0.0.1:ReplyMsg:(#4):ip=null,host=localhost:MSG_SUCCESS:::result class:com.collation.discover.result.app.j2ee.WebSphereResult 2008-05-17 11:52:54,558 [Thread: 0,8495] DEBUG cdb.AnchorServer[0] server(0) readMessage:CloseMsg:(#160):ip=127.0.0.1,host=localhost: SERVER_HALT:SEND_STATS 2008-05-17 11:52:54,559 [Thread: 0,8495] DEBUG cdb.AnchorServer[0] server(0) sendMessage to:127.0.0.1:StatsMsg:(#5):ip=null,host=localhost:1 connections,0 classes,3/6 messages,1 agents 2008-05-17 11:52:54,568 [Thread: 0,8495] DEBUG cdb.AnchorServer[main] - halt: just told to halt 2008-05-17 11:52:54,568 [Thread: 0,8495] DEBUG cdb.AnchorServer[main] - doAbort: aborting all threads v The JVM runtime information that is the Java version and publisher name is discovered for each server that is running. The discovery of the runtime information 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 most current information is gathered from the cell after the JVM information is propagated from the node agent. v When discovering a distributed WebSphere Application Server, the JDBC driver version is discovered only for JDBC providers that have a class path valid for the host running the deployment manager process. v The JDBC driver version for JDBC providers is not discovered for WebSphere Application Servers running on z/OS

Model objects created


The sensor creates the following model objects: v app.AppConfig v app.AppServer v app.ConfigFile v app.SoftwareContainer v app.j2ee.J2EEComponent v app.j2ee.J2EEDeployedObject v v v v v app.j2ee.J2EEModule app.j2ee.J2EEResource app.j2ee.JDBCDriver app.j2ee.websphere.WebSphereAuthMappingModule app.j2ee.websphere.WebSphereCell

46

Application Dependency Discovery Manager: Sensors

v v v v v v v v v v v v v v v v v v

app.j2ee.websphere.WebSphereCluster app.j2ee.websphere.WebSphereConfiguredConnection app.j2ee.websphere.WebSphereConnector app.j2ee.websphere.WebSphereConnectorModule app.j2ee.websphere.WebSphereCustomUserRegistry app.j2ee.websphere.WebSphereDeploymentManager app.j2ee.websphere.WebSphereDynamicCache app.j2ee.websphere.WebSphereEFixInfo app.j2ee.websphere.WebSphereEJB app.j2ee.websphere.WebSphereEJBModule app.j2ee.websphere.WebSphereGlobalSecuritySettings app.j2ee.websphere.WebSphereJ2EEApplication app.j2ee.websphere.WebSphereJ2EEResource app.j2ee.websphere.WebSphereJ2EEResourceProperty app.j2ee.websphere.WebSphereJDBCConnectionPool app.j2ee.websphere.WebSphereJDBCDataSource app.j2ee.websphere.WebSphereJDBCProvider app.j2ee.websphere.WebSphereJMSDestination

v app.j2ee.websphere.WebSphereJMSProvider v app.j2ee.websphere.WebSphereJMSQueue v app.j2ee.websphere.WebSphereJMSTopic v v v v v v v v v v v v app.j2ee.websphere.WebSphereLDAPUserRegistry app.j2ee.websphere.WebSphereLibraryRef app.j2ee.websphere.WebSphereMQJMSDestination app.j2ee.websphere.WebSphereMQJMSQueue app.j2ee.websphere.WebSphereMQJMSTopic app.j2ee.websphere.WebSphereNamedEndpoint app.j2ee.websphere.WebSphereNode app.j2ee.websphere.WebSphereNodeAgent app.j2ee.websphere.WebSphereServlet app.j2ee.websphere.WebSphereServer app.j2ee.websphere.WebSphereSessionTuningParams app.j2ee.websphere.WebSphereSharedLibrary

v app.j2ee.websphere.WebSphereSSLSettings v app.j2ee.websphere.WebSphereUserRegistry v v v v app.j2ee.websphere.WebSphereVariable app.j2ee.websphere.WebSphereVirtualHost app.j2ee.websphere.WebSphereWebModule app.JVM

Asynchronous and script-based discovery support


The IBM WebSphere sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration.
Chapter 2. Application sensors

47

See the TADDM Administrator's Guide for information about configuring for script-based discovery.

Access list configuration requirements


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

Limitations
Some function that is provided by the WebSphere sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. Application descriptor discovery is not supported. The following model objects are not supported: v app.j2ee.websphere.WebSphereCluster v v v v v app.j2ee.websphere.WebSphereConfiguredConnection app.j2ee.websphere.WebSphereConnector app.j2ee.websphere.WebSphereConnectorModule app.j2ee.websphere.WebSphereCustomUserRegistry app.j2ee.websphere.WebSphereDynamicCache

v app.j2ee.websphere.WebSphereEFixInfo v app.j2ee.websphere.WebSphereGlobalSecuritySettings v v v v v app.j2ee.websphere.WebSphereJMSDestination app.j2ee.websphere.WebSphereJMSProvider app.j2ee.websphere.WebSphereJMSQueue app.j2ee.websphere.WebSphereJMSTopic app.j2ee.websphere.WebSphereLDAPUserRegistry

v app.j2ee.websphere.WebSphereLibraryRef v app.j2ee.websphere.WebSphereMQJMSDestination v app.j2ee.websphere.WebSphereMQJMSQueue v v v v v app.j2ee.websphere.WebSphereMQJMSTopic app.j2ee.websphere.WebSphereNodeAgent app.j2ee.websphere.WebSphereServlet app.j2ee.websphere.WebSphereSessionTuningParams app.j2ee.websphere.WebSphereSharedLibrary

v app.j2ee.websphere.WebSphereSSLSettings v app.j2ee.websphere.WebSphereUserRegistry v app.j2ee.websphere.WebSphereVirtualHost v app.JVM

Configuring the sensor


Before running a discovery, depending on the type environment you might have to configure the IBM WebSphere sensor.

48

Application Dependency Discovery Manager: Sensors

Enabling JDBC driver discovery


If you want to discover JDBC driver information, you must enable the WebSphere JDBC 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 a different prefix for UNIX and Windows systems. By default, a prefix is not defined. v You can configure for the sensor to remove the OracleUtility file after discovery completes. The OracleUtility file is an auxiliary file used by TADDM on target hosts to discover JDBC driver information for Oracle databases. By default, the OracleUtility file is not removed.

Configuring the discovery profile


If you want to change the discovery level, update the discovery profile for the IBM WebSphere sensor. To change the default the discovery level for this sensor, complete the following steps: 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 Enable Configuration check box. 5. In the Configuration section of the Create Configuration window, to change the 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 deepDiscoveryLevel and change from false to true If deepDiscoveryLevel is set to true, it runs a deep discovery regardless if shallow 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.

Chapter 2. Application sensors

49

For more information about Discovery Profiles, see the Using topics in the IBM Tivoli Application Dependency Discovery Manager information center.

Sensor properties
shallowDiscoveryLevel, mediumDiscoveryLevel, deepDiscoveryLevel The WebSphere sensor has three discovery levels, shallow, medium, and deep. By default the shallow discovery level is enabled. To modify the discovery 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 regardless of 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 J2EE 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

50

Application Dependency Discovery Manager: Sensors

Custom properties Deployment descriptors for J2EE 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 the WebSphere client code called by the TADDM WebSphere sensor. sample value - Admin=all=enabled Caution: The preceding value generates verbose trace logging. Not setting any value prevents trace logging. traceOutputFile Allows you to specify the full path name of the output file to be used for logging 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 WebSphere sensor for troubleshooting purposes. FFDC logs capture the failure path through the WebSphere client code in a subdirectory named ffdc in the directory specified in this property. Not setting a value ensures that FFDC is not enabled. The directory must exist and the TADDM user must have write access.

Configuring the access list


This topic describes the access details you require depending on type of configuration that you are using. 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. The WebSphere Application Server user and password b. The client side SSL certificate (two files, trust and keystores, with their passphrases - the default 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 an account with appropriate privileges. If the WebSphere SSH access list is not specified, the WebSphere JDBC 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 the information. Only the administrator role discovers security configuration information for WebSphere Application Server. 5. Disabling security does not mean that you are not using SSL. Check whether you are prompted for a password when you connect to the WebSphere Application Server Admin Console.
Chapter 2. Application sensors

51

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.

Certificate setup
If security is enabled when discovering WebSphere Application Server, TADDM requires that SSL certificates are set in the access list entries. TADDM supports PKCS12 and JKS certificate store types. The truststore and keystore files must be present on the computer running the TADDM console, not the TADDM server. Truststore and keystore files are typically found in the $PROFILE_HOME/etc directory on the system where WebSphere Application Server is installed. By default, the following 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 and keystore files by downloading certificates using the WebSphere Application Server console. TADDM requires a truststore with signer certificate only for connecting with dmgr, 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 from WebSphere Domain Manager or from a stand-alone server (certificates caching per session), TADDM can handle only one truststore file for a single discovery. The certificates that are stored in the truststore file are loaded when connection with WebSphere Application Server is established. Only those certificates can be used by TADDM during the entire discovery, so if certificates from several truststores are required, attaching them separately into appropriate access list entries won't work. You must export the original truststores to a single file. When all necessary entries for each WebSphere server are created in the TADDM access list (one for each different login/password combination for discovered WebSphere servers), the very first one must have the exported truststore and keystore files attached. To create a pair of keystore and truststore files (for PKCS12, the .p12 files, and for JKS, the .jks files) that contain all required certificates, complete the following steps: 1. Extract all certificates from the common keystore or truststore for each server. To do this, complete 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.

52

Application Dependency Discovery Manager: Sensors

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 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 are using JKS truststores, add the exported signer certificates to the .jks files. To do this for the default DummyServerTrustFile.jks and DummyClientTrustFile.jks files, complete the following steps (if you are using PKCS12 truststores, follow the same procedure for key.p12 and trust.p12 files): a. To open the key management utility, iKeyman, run ikeyman.sh, or ikeyman.bat, from the WebSphere_Root/profiles/dmgr_profile/bin directory. 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 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 and key.p12, are typically located 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 need to use different certificates, do not attempt to edit the certificates. Delete the old access list entry and create an appropriate access list entry.

Access to Configuration Files


v In general, the WebSphere Application Server sensor captures the following configuration files: WebSphere Application Server cell WebSphere Application Server node WebSphere Application Server server This information is made available for the change history over time. It is also made visible in the Discovery Management Console (Configuration files tab of the Details panel) for each of the preceding configuration items. v When the sensor starts, it also uses the following two files to make key decisions about the discovery of WebSphere Application Server: $WAS_ROOT/config/cells/cell_name/cell.xml

Chapter 2. Application sensors

53

This helps to determine if the system is ND or stand-alone WebSphere Application Server. If read access to this file is not available, the sensor continues and uses JMX to determine whether it is an ND or stand-alone WebSphere Application Server. $WAS_ROOT/config/cells/cell_name/nodes/node_name/serverindex.xml (for ND, node_name is the dmgr's node, for stand-alone mode, there is only one node) This helps to determine the port on which the JMX SOAP connector is listening. If read access to this file is not available, the sensor attempts to set up a JMX connection by cycling through all the listen ports of the WebSphere Application Server server/dmgr being discovered. The ports are tried in ascending order since this method results in quicker identification of the JMX port.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the IBM WebSphere sensor uses. com.collation.discover.localanchor.timeout=7200000 com.collation.discover.agent.WebSphereAgent.timeout=7200000 com.collation.discover.agent.WebSphereNodeSensor.timeout=7200000 The default value is 7200000, which means 7,200,000 milliseconds (or 2 hours). These properties set the time allowed for the WebSphere sensor to run. If you have a large WebSphere environment and require medium or deep discovery levels, you might need to increase the value so that the sensor has enough time to discover the environment. com.collation.discover.websphere.jmx.timeout= This property sets the time allowed for opening a JMX connection to WebSphere. By default, the value is 600000 milliseconds (10 Minutes) com.collation.discover.agent.WebSphereVersionAgent.versionscript=sudo This property can be enabled for access to the WebSphere versionInfo.sh file if the discovery user does not have access on the target WebSphere Application Server system.

Using the WebSphere seed sensor for z/OS


TADDM does not support an operating system sensor for a z/OS system. To discover WebSphere resources on a z/OS system, the WebSphere sensor is enhanced to support discovery initiated from user-created seed files. Because there is no z/OS system sensor, you must use the WebSphere Application Server seed utility for the z/OS DLA. This utility creates an XML seed file from a z/OS IDML book. This file contains information about the WebSphere resources that you are trying to discover on the z/OS system. After this seed file is created, on the next discovery, the WebsphereIdmlSeedSensor looks for z/OS WebSphere seed files on the TADDM server. If there are, it parses that seed file and create a real discovery seed file that is used to kick off the WebSphere sensor. The WebSphere sensor then does a deeper discovery of WebSphere on this z/OS system. To install and configure the WebSphere Application Server seed utility for the z/OS DLA, see the corresponding section.

54

Application Dependency Discovery Manager: Sensors

Preparing to run the WebSphere seed sensor


Before 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 DLA, use the utility that is provided in the Tivoli Open Process Automation Library (OPAL) at http://www.ibm.com/software/tivoli/opal. This utility generates the seed files automatically from the IDML books created from the z/OS DLA. For information about this utility, see the topic Installing the WebSphere Application Server seed utility for the z/OS DLA. v To discover WebSphere on a non-mainframe system by manually creating the seed file, use the following file naming conventions when creating the seed file: 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> <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_DIR The directory path where the WebSphere Application Server is installed. WAS_VERSION The version of the WebSphere Application Server, which can be found in the product file in the <WebSphere Root Directory>/properties/version directory. SOAP_CONNECTOR_PORT The port number is retrieved from the serverindex.xml file for the SOAP_CONNECTOR_ADDRESS endpoint name. For example, <WebSphere Root Directory>/profiles/<app server or dmgr>/conf/cells/<cell name>/nodes/<node name> If the resource is a deployment manager, use the serverindex.xml file with the following value specified: serverType="DEPLOYMENT_MANAGER". If the resource is stand-alone component, use the serverindex.xml file with the following value specified: serverType="APPLICATION_SERVER"
Chapter 2. Application sensors

55

RMI_CONNECTOR_PORT The port number is retrieved from the same serverindex.xml file used to find the soap port, where the endpoint name is BOOTSTRAP_ADDRESS. JMX_LISTEN_IP_ADDRESS The IP address that is used to connect through JMX. Typically this address is the same IP address as the WebSphere server. HOST_MAPPINGS A list of mappings between the host name and IP address for the WebSphere Application Server or Deployment Manager and each distributed Node Agent. HOST_MAPPING One host mapping consisting of a host name, primary IP address, and IP address. HOST_NAME The fully qualified domain name. PRIMARY_IP_ADDRESS The primary IP address that the host name resolves to. IP_ADDRESS The IP address that the host name resolves to, if different from the primary IP address. 2. Place the .xml files in the $COLLATION_HOME/var/dla/zos/was directory. If the directory does not exist, create the directory. The scope of discovery is controlled by the files in this directory. If discovery of a particular WebSphere server is no longer needed, the file must be removed from this directory or renamed without the .xml extension. 3. Create a new sensor configuration file when you run the WebSphere seed sensor. 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 are located. <scope> Set this tag to the IP address of the TADDM server where the WebSphere XML seed files are located. Related reference: Installing the WebSphere Application Server seed utility for the z/OS DLA on page 57 To discover the WebSphere product on a z/OS system, use the WebSphere Application Server seed utility for the z/OS DLA. This utility creates the XML seed files from the IDML book. If you do not use this utility, you must manually create the XML seed files.

Running the WebSphere seed sensor


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

56

Application Dependency Discovery Manager: Sensors

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. You also need the client-side SSL certificate when creating the Access List entry. This certificate must be exported from the mainframe security product for example, Resource Access Control Facility (RACF) and transferred to a tool for maintaining digital certificates. Use this tool for example iKeyman, to generate a JKS or PKCS12 file. This file contains the client-side SSL certificate in a format that can be used by TADDM. The JKS or PKCS12 file must then be used for the SSL settings in the TADDM WebSphere Access List entry for both keystore and truststore certificates. 6. Complete the following steps: a. Configure the IdmlFileUDS sensor using the Discovery Management Console: In the Discovery Profiles window, click IdmlFileUDS. Click New. Type the sensor configuration name and description. Select Enable Configuration. Double-click /data/latest/dist/var/dla/zos/was and type the location of the WebSphere XML seed files. This location is the server where the WebSphere seed file is located. 6) Double-click 0.0.0.0 and type the IP address of the machine on which the seed file is located. b. Create a discovery profile that includes the following sensors: 1) 2) 3) 4) 5) v Anchor Sensor v Sensor name entered in step a. (The modified IdmlFileUDS sensor created previously.) v PortSensor v PingSensor v v v v SessionSensor GenericServerSensor WebSphereIdmlSeedSensor WebSphereCellSensor

v WebSphereNodeSensor v WebSphereSensor (select this sensor instead of WebSphereCellSensor and WebSphereNodeSensor only if com.collation.websphere.performance.setting=false) The sensors can require additional sensors to be enabled in the profile by default, 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.

Installing the WebSphere Application Server seed utility for the z/OS DLA
To discover the WebSphere product on a z/OS system, use the WebSphere Application Server seed utility for the z/OS DLA. This utility creates the XML seed files from the IDML book. If you do not use this utility, you must manually create the XML seed files.
Chapter 2. Application sensors

57

To download the utility, complete the following steps: 1. Go to the Tivoli Open Process Automation Library (OPAL) site at http://www.ibm.com/software/tivoli/opal. 2. Enter the following search criteria: WebSphere Application Server seed utility for the z/OS DLA. 3. From the search results, click WebSphere Application Server seed utility for the z/OS DLA. 4. Follow the instructions on the Web page to download the utility. After downloading the utility, read the documentation for installing and using the utility.

Troubleshooting the sensor


This topic describes common problems that occur with the IBM WebSphere sensor and presents solutions for those problems.

Sensor does not start


Problem The 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 z operating systems, the command line must contain the word WsServer. v The WebSphere Application Server was started as a service (on Windows 2000), or as a service or from the command line (Windows 2003 or Windows 2008). If none of the preceding items appear to be the cause, check the system log and the WebSphere Application Server start logs for error messages.

Discovery of WebSphere Application Server is not logged


Problem The discovery of the WebSphere Application Server is not logged in the DiscoverManager.log file. Because a local anchor is used for the discovery, the log messages are placed in to a separate file. Solution The log messages are placed in the following log files, where hostname is the 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 Application Server


Problem The 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 at

58

Application Dependency Discovery Manager: Sensors

9.48.158.37:8,880 - ADMC0016E: The system cannot create a SOAP connector to connect to host 9.48.158.37 at port 8880... v ERROR cdb.WebSphereJMXUtils - An error occurred, unable to establish a repository connection using the credentials raleigh-was60: com.ibm.websphere.management.exception.AdminException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the getServerConfig operation on FileTransferServer MBean because of insufficient or 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. Solution Add the credentials in the access list for the WebSphere Application Server. Correct the certificates, enter the certificates through the access list, or provide the correct password.

Failure to make a JMX connection


Problem The 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 Application Server through the SOAP port. v The WebSphere Application Server might not be in a good state, even though the process shows up in the process table or Windows services list. To test the state of the WebSphere Application Server, try to connect to it using the wsadmin WebSphere administrative utility. If the wsadmin utility fails, the sensor has problems also. Solution Run one of the following programs, which tests the JMX connection to verify credentials and connectivity: v For Linux, Solaris, AIX, and Linux on System z operating systems: $COLLATION_HOME/bin/testwasconnection.sh. Instructions for running this program are in the testwasconnection.sh file.

Chapter 2. Application sensors

59

v For Windows systems: %COLLATION_HOME%\bin\testwasconnection.bat. Instructions for running this program are in the testwasconnection.bat file. Verify that the version of the WebSphere Application Server, that the sensor is to discover matches the version of the WebSphere Application Server JAR files on the TADDM server. If a class is missing, ensure that the correct JAR files are in the correct location.

Sensor fails on a JMX query


Problem The sensor fails on a JMX query with the following message:
failed on JMX query--check server health and retry

This error indicates the following problems: v The configuration setup might be corrupted. v A defect in the sensor might cause the missing configuration value to be treated as necessary for discovery progress and might end unnecessarily Solution Check the logs to see what is being queried and whether that value is readable in the WebSphere Application Server console. This error usually occurs because discovery is run overnight, and WebSphere Application Servers are down for maintenance reasons. In this case, restart the server, and try the discovery again.

Data store error - schema not updated


Problem The schema was not updated accurately for the version of TADDM that is installed. Solution Drop and re-create the database.

Data store error - duplicate objects


Problem The amount of sensor data that is stored is too large and is causing duplicate objects to be stored. To see this error, the logging level must be set to DEBUG. Solution Identify the model object that the topology manager had difficulty in storing. The problem might be that too many objects are being stored in the same table for the database. Consult IBM Software Support to resolve this issue.

Data store error - value too large to fit


Problem A value cannot be stored because it exceeds the maximum valid length for a column in the database. The error message is in the TopologyManager.log file, but to see this error, the logging level must be set to DEBUG. Solution Look for database exceptions complaining about the value being too large to fit into the column. Determine the table and column that contains the problem, update the schema, and re-create the database.

60

Application Dependency Discovery Manager: Sensors

Data store error - storage of data taking too long to collect


Problem Storage of data collected from a WebSphere discovery is taking too long. Solution The database tuning script was not run before TADDM schema creation. Before creating the TADDM schema, run the following database tuning script: 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


Problem The WebSphere Application Server is down for one of the following reasons: v TADDM runs when a WebSphere Application Server is in maintenance, and a discovery does not complete. The localanchor*.hostname.WebSphereAgent.log file or localanchor*.hostname.WebSphereNodeSensor.log file might display the following error message:
INFO cdb.AnchorServer[main] - [AnchorServer.I.0] server no longer accepting new connections

v An error message states that the query cannot be completed. Solution Verify that the WebSphere Application Server is functioning properly.

Web services cannot be discovered


Problem Web services cannot be discovered. Solution TADDM can discover Web services only for the Version 6 releases of WebSphere Application Server. To discover Web services for a Version 6 release of WebSphere Application Server, you must set the deepDiscoveryLevel property to true in the sensor configuration as part of the Discovery Profiles.

Sensor does not show as much data as it did in previous releases of TADDM
Problem The Details window for WebSphere cells, nodes, and servers does not show as much detail as it did in previous TADDM releases, and many of the tabs in the window have no data. Solution TADDM implements the following discovery levels: v Shallow v Medium v Deep

Chapter 2. Application sensors

61

The default discovery level for the WebSphere Application Server sensor is shallow. To obtain more detail about the WebSphere Application Server, create a discovery sensor configuration for the WebSphereCellSensor sensor, and in the Sensor Configuration window. Set the value of the mediumDiscoveryLevel property or the deepDiscoveryLevel property to true.

WebSphere sensor fails during WebSphere discovery on an AIX operating system due to problems with the AIX ps command
Problem On some AIX operating systems, running the UNIX ps command returns truncated Java CLASSPATH strings. The strings are not recognized by the TADDM WebSphere sensor, resulting in a failed discovery. Solution Upgrade to at least the AIX 5.3. FP5 (5.3.0.50) version. This version and later versions of AIX return the full Java CLASSPATH strings.

Message CTJDT0736W is shown


Problem Insufficient credentials exist in the access list for the Secure Shell (SSH) protocol or Windows Management Instrumentation (WMI) on the host system where the distributed node is running. The computer system credentials for this host system are used to retrieve information to populate the host for the node and server configuration items on that system. Solution If you want this information to be populated, you must add the appropriate computer system credentials for the host system.

WebSphere sensor fails and the following message is displayed: CTJTD0692E


Problem While attempting discovery of a WebSphere Deployment Manager (Version 6.1), the WebSphere sensor fails with the following message:
CTJTD0692E The distributed cell deployment manager bind address is not found for the following cell:etabsap1TCell

Solution Discoveries involving the sensors related to WebSphere Deployment Manager must have a working DNS. As a workaround, change com.collation.platform.os.disableRemoteHostDNSLookups to true, and ensure that the TADDM server always has the correct DNS search path.

WebSphere sensor fails and the following message is displayed: CTJTD3021E


Problem The 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 not

62

Application Dependency Discovery Manager: Sensors

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

Solution Verify that the problem is with the SSL support in the WebSphere client code. To verify, ensure that the WebSphere access list entry for this WebSphere Server is first in the access list (before any other WebSphere credentials). If the discovery is successful, import all the WebSphere certificates from the different servers into one truststore. Having multiple access list entries with different user IDs and passwords is acceptable. However, all the access list entries must specify the same truststore, which contains all the certificates. For additional information, see Configuring the access list on page 51.

WebSphere JDBC driver sensor does not start


Problem The WebSphere JDBC driver sensor does not start. Solution To establish why the WebSphere JDBC driver sensor does not start, ensure that 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 target host and the following message is displayed: CTJTD0796E
Problem During the discovery, the WebSphere JDBC driver sensor cannot establish a connection with target host and the CTJTD0796E error message is displayed. Solution The 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 situations has occurred. If the sensor fails and the warning CTJTD0798W is displayed in the log files, ensure that the user specified in the WebSphere SSH access list entry has the appropriate privileges to run the WebSphere setupCmdLine script. If the sensor fails and the warning CTJTD0799W is displayed in the log files, ensure that the user specified in the WebSphere SSH access list entry has the appropriate privileges to run the Java command.

Chapter 2. Application sensors

63

IBM WebSphere eXtreme Scale cache sensor


The IBM WebSphere eXtreme Scale cache sensor discovers IBM WebSphere eXtreme Scale caches and some of their components. The sensor discovers the following elements for the eXtreme Scale cache: v The name of the cache v 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 node v The host name of the node v The contents of the main configuration file v The contents of the orb.properties configuration file for the JVM that runs this node and version of this JVM v The contents of .xml, .sh, .props, and .properties files that are in the same directory as main configuration file

Sensor name that is used in the GUI and logs


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 information is to be captured. v Run the JVM that runs the eXtreme Scale node with the -version parameter, to get runtime environment version information. v Read the orb.properties configuration file, which is in the lib directory of the JVM.

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 as containers for eXtreme Scale nodes are not discovered. v JVMs that provide catalog services for eXtreme Scale nodes are not discovered.

64

Application Dependency Discovery Manager: Sensors

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, the sensor does not recognize that they are separate nodes, and the nodes are merged. v The sensor looks for configuration files only in the same directory as the configuration file specified by the -objectgridfile parameter, and its subdirectories. 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 attributes


The IBM WebSphere eXtreme Scale cache sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about configuration items in the IBM WebSphere environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. app.JVM ExecutableName JVMVersion Publisher SoftwareVersion websphere.WebSphereXSCache v Name websphere.WebSphereXSCacheNode v Name v Host

Configuring the sensor


Before running a discovery, you must configure the sensor. 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.

IBM WebSphere Message Broker sensor


The IBM WebSphere Message Broker sensor discovers WebSphere Message Broker attribution at broker instance, configuration, and application levels for Windows and UNIX.

Chapter 2. Application sensors

65

Sensor name that is used in the GUI and logs


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.

Model objects created


The sensor creates the following model objects: v messaging.mb.MBBroker v messaging.mq.MQQueueManager v messaging.mb.MBExecutionGroup v messaging.mb.MBHTTPListenerProperties v messaging.mb.MBHTTPConnectorProperty v v v v v messaging.mb.MBHTTPSConnectorProperty messaging.mb.MBHTTPListenerProperty messaging.mb.MBBrokerSecurity messaging.mb.MBBrokerProfile messaging.mb.MBMessageFlow

v messaging.mb.MBMessageFlowNode v messaging.mb.MBBarFile v messaging.mb.MBProperty

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the discovery profile


If you want to change the discovery level, update the discovery profile for the IBM WebSphere Message Broker sensor. To change the default the discovery level for this sensor, complete the following steps: 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 value for useNodeLevel and change from false to true

66

Application Dependency Discovery Manager: Sensors

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 topics in the IBM Tivoli Application Dependency Discovery Manager information center.

Configuring the access list


This 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 name v Password You must be authorized to run mqsiprofile command.

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.platform.os.UnixOs.forcedServerList=bipbroker This property forces the bipbroker process to start the sensor on UNIX platform. com.collation.platform.os.WindowsOs.forcedServerList=bipservice This property forces the bipservice process to start the sensor on Windows platform.

Troubleshooting the sensor


This topic describes common problems that occur with the IBM WebSphere Message Broker sensor and presents solutions for those problems.

The sensor does not start


Problem The WebSphere Message Broker sensor does not start. Solution Make sure that the bipbroker process name is added to the com.collation.platform.os.UnixOs.forcedServerList property in the collation.properties file.

IBM WebSphere MQ Server sensor


The IBM WebSphere MQ Server sensor discovers IBM WebSphere MQ servers.

Sensor name that is used in the GUI and logs


MQServerSensor

Chapter 2. Application sensors

67

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.

Model objects created


The sensor creates the following model objects: v app.messaging.mq.MQChannel v app.messaging.mq.MQClientConnectionChannel v app.messaging.mq.MQCluster v v v v v v v app.messaging.mq.MQClusterReceiverChannel app.messaging.mq.MQClusterSenderChannel app.messaging.mq.MQInstallation app.messaging.mq.MQListener app.messaging.mq.MQNameList app.messaging.mq.MQTCPListener app.messaging.mq.MQQueueManager

v app.messaging.mq.MQRequesterChannel v app.messaging.mq.MQServerChannel v app.messaging.mq.MQTCPListener v app.ProcessPool

Asynchronous and script-based discovery support


The IBM WebSphere MQ Server sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. See the TADDM Administrator's Guide for information about configuring for script-based discovery.

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 for nonscript-based discovery.

Limitations
Some function that is provided by the WebSphere MQ Server sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. Application descriptor discovery is not supported.

68

Application Dependency Discovery Manager: Sensors

Configuring the sensor


Before running a discovery, you must configure the sensor. The sensor supports application descriptors. Create the appdescriptors directory with appdescriptors files inside the WebSphere MQ Queue Manager data directory. For example, in a Linux environment, this directory is /var/mqm/qmgrs/test5/appdescriptors. The test5 directory is a Queue Manager name. Read access to that directory must be granted for the mqm user that is used to discover that manager.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. To configure the access list, complete the following steps: 1. Select Messaging Servers as the Component Type. 2. Select WebSphere MQ as the Vendor. 3. Specify the following required information: v User name v Password Ensure that the WebSphere MQ user you add to the access list has privileges to run the runmqsc command.

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.platform.os.UnixOs.forcedServerList=amqzxma0 This property forces the aqmzxma0 process to start the sensor. com.collation.topobuilder.mq.clusterrelations=true This property enables the building of dependencies based on cluster membership. Every Queue Manager in the cluster has two dependencies (one as a source and one as a target) to every other Queue Manager in the same cluster. If not set, the default value is false. com.collation.topobuilder.mq.channelrelations=true This property enables the building of dependencies based on sender-receiver channel names. If not set, the default value is false. Limitation: This capability is available only if the channel names contain both the name of the source manager and the target manager. Otherwise, it is not possible to build a regular expression for the com.collation.topobuilder.mq.channelnaming property. com.collation.topobuilder.mq.checkreceiverchannelname=true If set to true, the dependency is set only if there is a receiver channel with a name matching the sender channel name on the target manager. The default value is false. com.collation.topobuilder.mq.channelnaming=<REGULAR EXPRESSION> Allows you to specify custom channel naming rules for creating channel dependencies. REGULAR_EXPRESSION must return two named groups: v The first matches the source manager name.
Chapter 2. Application sensors

69

v The second matches the target queue manager name. If the custom channel naming does not contain the source queue manager name, for example, TO.TARGET_MANAGER, the first group can be set to an empty value, for instance, ()TO.(.*). The source queue manager name is not compared with the sender channel parent queue manager name in that case. If not set, the default value for the <REGULAR_EXPRESSION) is CH\\.(.*?)\\.TO\\.(.* The following properties are used for generating display names for the QueueManager. 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 Qualified Domain Name (FQDN) or IP from the first listening MQListener is used com.collation.discover.agent.MQQueueManager.UseIpFromConnections=true The 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=true If the FQDN is not present, the first non-empty FQDN (or IP) taken from the LOCLADDR attribute of the ClientConnection is used. The default value is false. <QUEUE_MANAGER_NAME> - The QueueManager name without the FQDN is used. com.collation.topobuilder.mq.removerelations If not set, the default value is false. If set to true, dependencies for the WebSphere MQ queue manager are removed if the state is other than running. If none of the preceding properties are set to true (UseListenningIp or UseIpFromConnections did not resolve the FQDN) <HOST_FQDN>:<QUEUE_MANAGER_NAME> - The parent host FDQN is used The following properties are used to specify that the sensor should use the sudo command when running MQ commands on the server. com.collation.discover.agent.MqServerAgent.versionCommand=sudo -u user Specifies that the sensor should use sudo with the specified user name when running the MQ version command. com.collation.discover.agent.MqServerAgent.statusCommand=sudo -u user Specifies that the sensor should use sudo with the specified user name when running the MQ dspmq command. com.collation.discover.agent.MqServerAgent.mqscCommand=sudo -u user Specifies that the sensor should use sudo with the specified user name when running the MQ runmqsc command. Each of the preceding properties can be scoped to a particular operating system type, IP address, or both, as in the following example:
com.collation.discover.agent.MqServerAgent.mqscCommand.Linux.1.2.3.4=sudo -u mqm

70

Application Dependency Discovery Manager: Sensors

Troubleshooting the sensor


This topic describes common problems that occur with the IBM WebSphere MQ Server sensor and presents solutions for those problems.

Sensor does not start


Problem The WebSphere MQ Server sensor does not start. Solution Ensure that the amqzxma0 process name is added to the com.collation.platform.os.UnixOs.forcedServerList property in the collation.properties file.

iPlanet server sensor


The iPlanet server sensor discovers iPlanet Web servers.

Sensor name that is used in the GUI and logs


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

Model objects created


The sensor creates the following model objects: v app.AppConfig v app.SoftwareContainer v v v v v v v v app.SoftwareModule app.StaticContentModule app.web.CGIScript app.web.iplanet.IPlanetJSP app.web.iplanet.IPlanetJVMSettings app.web.iplanet.NSAPIPlugin app.web.iplanet.IPlanetServer app.web.iplanet.IPlanetServlet

v app.web.iplanet.IPlanetSSLSettings v app.web.iplanet.IPlanetVirtualHost v v v v app.web.iplanet.IPlanetWebContainer app.web.iplanet.WebLogicConnection app.web.WebConnection sys.DataFile sys.Directory

JBoss server sensor


The JBoss server sensor discovers JBoss Application Server servers.

Chapter 2. Application sensors

71

Sensor name that is used in the GUI and logs


JBoss4xSensor

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 password protected, the credentials must be entered in the access list. v Ensure the jbossall-client.jar, jnpserver.jar, and jboss-jmx.jar are copied from the JBoss server. These files are located in the dist/lib/jboss/402/ directory.

Model objects created


The sensor creates the following model objects: v app.AppServer v v v v v app.j2ee.J2EEServer app.j2ee.jboss.JBossCluster app.j2ee.jboss.JBossDomain app.j2ee.jboss.JBossJMSServer app.j2ee.jboss.JBossServer

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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.

Troubleshooting the sensor


This topic describes common problems that occur with the JBoss server sensor and presents solutions for those problems.

JBoss4xServerSensor does not launch


Problem The JBoss4xServerSensor does not launch. Solution Check the following: v Type http://ipaddress:webport/jmx-console in a browser and scroll through the console to see if the JBoss server JMX console is enabled. v Ensure that lsof is working.

JBoss libraries not found


Problem You see the message JBoss libraries not found while running the sensor.

72

Application Dependency Discovery Manager: Sensors

Solution Ensure that the JBoss JAR files for the JBoss server version you are running are present in the dist directory with read access for the TADDM server user.

LDAP sensor
The LDAP sensor discovers LDAP servers.

Sensor name that is used in the GUI and logs


LdapSensor

Limitations
The sensor discovers LDAP only when the LDAP service listens on port number 389 and accepts plain text authentication. Discovery cannot occur if LADP server requires encryption or a port number other than 389 is used.

Model objects created


The sensor creates the model object sys.LDAPSAP.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. To configure the access list, complete the following steps: 1. Use LDAP Service as the Component Type. 2. Specify the access information (user name and password) that TADDM should use to authenticate with the LDAP server.

Troubleshooting the sensor


This topic describes common problems that occur with the LDAP sensor and presents solutions for those problems.

Error occurs during a discovery


Problem The 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]

Solution The LADP server requires encryption. The LADP sensor cannot carry out a discovery if the LADP server requires encryption, disable the encryption on the LADP server.

Sensor cannot display all attribute information


Problem The following attribute information is not displayed after running a discovery: LDAP Version, Threads, and Total Connections. Solution Enable the LDAP application monitor to discover LDAP Version, Threads, and Total Connections.
Chapter 2. Application sensors

73

Microsoft Cluster sensor


The Microsoft Cluster sensor discovers a Microsoft Windows Server cluster installation. The sensor discovers only server clusters (includes a process known as failover) and not Network Load Balancing clusters. The sensor discovers the nodes, resources, and resource groups on the cluster.

Sensor name that is used in the GUI and logs


MSClusterSensor

Prerequisites
The MS Cluster sensor requires: v Successful discovery of Windows computer systems v The Cluster Server ClusSvc service, must be running v Using the TADDM Windows Management Instrumentation (WMI) provider, WMI read access to the root/mscluster namespace must be granted. If the discovery of the Windows computer systems succeeded, this WMI read access is granted by default. Administrative-level access is preferable.

Limitations
The scope of discovery must contain the IP address of at least one of the MS Cluster nodes or mention the cluster IP address. A node is any computer that is part of the cluster.

Model objects with associated attributes


The MS Cluster sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about Microsoft Server clusters in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. app.MsFailoverCluster.MsCluster v CrossSubnetDelay v CrossSubnetThreshold v DefaultNetworkRole v Description v DisableGroupPreferredOwnerRandomization v Domain v v v v v v v EnableEventLogReplication HangRecoveryAction HangTimeout InternalNetwork LogLevel LogSize MaintenanceFile

v MaxNumberofNodes v MaxQuorumArbitrationTime

74

Application Dependency Discovery Manager: Sensors

v v v v v v v v v v v v v v v v v v

MinQuorumArbitrationTime Name Nodes PlumbAllCrossSubnetRoutes PublicNetworks QuorumLogFileSize QuorumPath QuorumType RegroupOpeningTimeout RegroupPruningTimeout RegroupStageTimeout RegroupTick RequestReplyTimeout ResourceDllDeadlockPeriod ResourceGroups Resources SameSubnetDelay SameSubnetThreshold

v SecurityLevel v WitnessDatabaseWriteTimeout v WitnessRestartInterval app.MsFailoverCluster.MsClusterNode v Description v EnableEventLogReplication v InitialLoadInfo v LastLoadInfo v Name v NodeHighestVersion v NodeLowestVersion v System app.MsFailoverCluster.MsClusterResource v AppServers v CryptoCheckpoints v v v v v v v v v v v DeadlockTimeout DebugPrefix DeleteRequiresAllNodes DependsOnResources Description HasSeparateMonitor IpAddresses IsAlivePollInterval IsCoreResource IsLocalQuorumCapable IsPersistentState
Chapter 2. Application sensors

75

v v v v v v v v v v v

IsQuorumCapable LooksAlivePollInterval Name PendingTimeout RegistryCheckpoints RestartAction RestartDelay RestartPeriod RestartThreshold RetryPeriodOnFailure Type

app.MsFailoverCluster.MsClusterResourceGroup v AntiAffinityClassNames v AutoFailbackType v Description v FailbackWindowEnd v FailbackWindowStart v FailoverPeriod v FailoverThreshold v IsPersistentState v Name v Parent v Resources

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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.

Troubleshooting the sensor


This topic describes common problems that occur with the Microsoft Cluster sensor and presents solutions for those problems.

WMI service crashes


Problem WMI service crashes on target during discovery. Solution Ensure that all WMI-related fixes, including fix KB933061, are applied on the target system. If problems persist, use the following Microsoft utilities to troubleshoot WMI problems:

76

Application Dependency Discovery Manager: Sensors

WMIDiag The 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 that WMI is working correctly.

Microsoft Exchange Server sensor


The Microsoft Exchange Server sensor discovers Microsoft Exchange Server.

Sensor name that is used in the GUI and logs


ExchangeServerSensor

Prerequisites
The account TADDM uses to access the windows gateway must have an Active Directory 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.

Model objects created


The sensor creates the following model objects: v app.messaging.exchange.ExchangeAdministrativeGroup v app.messaging.exchange.ExchangeConnector v v v v v v v v v v v v v app.messaging.exchange.ExchangeDSAccessDomainController app.messaging.exchange.ExchangeFolderTree app.messaging.exchange.ExchangeLink app.messaging.exchange.ExchangeMailbox app.messaging.exchange.ExchangeMailboxStore app.messaging.exchange.ExchangeProtocolVirtualServer app.messaging.exchange.ExchangePublicFolder app.messaging.exchange.ExchangePublicFolderStore app.messaging.exchange.ExchangeQueue app.messaging.exchange.ExchangeRoutingGroup app.messaging.exchange.ExchangeScheduleInterval app.messaging.exchange.ExchangeServer app.messaging.exchange.ExchangeStorageGroup

Configuring the sensor


Before running a discovery, you must configure the sensor.

Chapter 2. Application sensors

77

Configuring the access list


This topic describes the access details that you require, depending on your configuration. To 1. 2. 3. configure the access list, complete the following steps: Select Messaging servers as the Component Type. Select Microsoft Exchange Server for the Vendor. Specify the following required information: a. User name b. 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.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. com.collation.discover.agent.exchange.command.timeout=600000 The default value is 600000 (in milliseconds), which is 10 minutes. The value must be an integer. This property specifies the timeout (in milliseconds) for the WMI call to get the Exchange Server information. If the WMI call takes a long time (which might occur in large environments), you can increase this value.

Troubleshooting the sensor


This topic describes common problems that occur with the Microsoft Exchange Server sensor and presents solutions for those problems.

Sensor is not started


Problem The Exchange Server sensor is not started. Solution For Microsoft Exchange Server 2003, ensure that the Microsoft Exchange Management service is started on the target Windows system. Run the services.msc program to check the status of the service.

Discovery does not find any systems


Problem The Exchange Server sensor completes successfully with the following message: There was nothing to be discovered. Solution No active Exchange Server is running on the target computer system. The following lists the possible causes: v The Exchange Management Tool is installed, but the Exchange Server is not installed. For Microsoft Exchange Server 2003, ensure the following things are done:

78

Application Dependency Discovery Manager: Sensors

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


Problem The Exchange Server sensor terminates with the following error message:
CTDTD0811E The Exchange Server Agent is unable to retrieve information from the Microsoft Exchange Server

Solution This error message means that no output was retrieved through the Windows Management Instrumentation (WMI). For Microsoft Exchange Server 2003, complete the following steps: 1. 2. 3. 4. Run the services.msc program on the target Windows system. Restart the Microsoft Exchange Management service. Run the discovery again. 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 not discovered
Problem The Exchange Server sensor terminates with the following error message: CTDTD0812E No Microsoft Exchange Server is found. Solution This error message means that no Exchange Server object exists in the output that was retrieved through the Windows Management Instrumentation (WMI). For Microsoft Exchange Server 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 still persists, see the sensors/ ExchangeServerSensor*.log file to determine if the problem is WMI related.

Sensor cannot access Windows Management Instrumentation (WMI) namespace


Problem The following message is in the sensors/ExchangeServerSensor-*.log file:
System.UnauthorizedAccessException: Access denied
Chapter 2. Application sensors

79

Solution The message typically means that the TADDM service account does not have 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\CIMV2 Root\CIMV2\Applications\Exchange Root\MicrosoftExchangeV2

configure the permission, complete the following steps: Click Start > Run > Open wmimgmt.msc. Right-click WMI Control (Local), and click Properties. 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 the Exchange 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 the server 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 v v v v Execute Read permissions List contents Read properties List object

To a. b. c.

v View information store status g. In the Exchange System Manager, expand Folders tree and find the folder tree object to be discovered. h. Do the same operation as described above for the server.

80

Application Dependency Discovery Manager: Sensors

WMI class does not exist


Problem The following message appears in the sensors/ ExchangeServerSensor*.log file:
System.Management. ManagementException: Invalid class

Solution The message typically means that the sensor tried to refer to a WMI class that does not exist. Possible causes include that the Exchange Server is not installed correctly, or the version of Exchange Server is not supported. Only Microsoft Exchange Server 2003 is supported. Microsoft Exchange Server 2007, 2000, and 5.5 are not discovered because these versions are not supported.

Unexpected discovery result


Problem The virtual servers for the following protocols are not discovered: v HTTP v IMAP4 v NNTP v POP3 Solution For Microsoft Exchange Server 2003, the sensor supports virtual servers for only SMTP and X400 protocols.

Microsoft Exchange 2007 Server sensor


The Microsoft Exchange 2007 Server sensor discovers Microsoft Exchange 2007 Server.

Sensor name that is used in the GUI and logs


Exchange2007Sensor

Prerequisites
The Exchange management tools and the Window PowerShell must be installed on the Exchange Server. To verify that the user account permissions are correct, run the following command on the Exchange Server while logged in as the TADDM discovery account:
C:\> powershell Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin;Get-ExchangeServer

Limitations
In the Exchange Server cluster environment, the sensor discovers only the active mailbox server.

Model objects with associated attributes


The Exchange 2007 server sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about Microsoft Exchange 2007 Servers resources in your IT environment.
Chapter 2. Application sensors

81

The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. app.messaging.exchange.AcceptedDomain v AcceptedDomainName v Default v DistinguishedName v DomainName v DomainType app.messaging.exchange.ActiveSyncVirtualDirectory v v v v v BasicAuthenticationEnabled ClientCertEnabled RemoteDocumentsActionForUnknownServers WebSiteName WebSiteSSLEnabled

app.messaging.exchange.ClientAccess v ClientAuthenticationMethod v ExternalHostName v OutlookAnywhereEnabled v SSLOffloading app.messaging.exchange.TransportServer v AntispamUpdatesEnabled v ConnectivityLogEnabled v ConnectivityLogPath v v v v v v v v v v v v v DelayNotificationTimeout ExternalDNSAdapterEnabled InternalDNSAdapterEnabled MaxOutboundConnections MaxPerDomainOutboundConnections MessageExpirationTimeout MessageTrackingLogEnabled MessageTrackingLogPath OutboundConnectionFailureRetryInterval ReceiveProtocolLogPath SendProtocolLogPath TransientFailureRetryCount TransientFailureRetryInterval

app.messaging.exchange.ExchangeConnector v Enabled v Fqdn v ProtocolLoggingLevel app.messaging.exchange.ExchangeJournalRule v EmailAddress v JournalRuleIdentity v Recipient

82

Application Dependency Discovery Manager: Sensors

v ReportNDRTo v Scope app.messaging.exchange.ExchangeMailbox v Alias v Mailbox v DisplayName v OrganizationalUnit v PrimarySmtpAddress v RecipientTypeDetails v UserDistinguishedName app.messaging.exchange.ExchangeMailboxStore v AllowFileRestore v CopyEdbFilePath v v v v v DeletedItemRetention IssueWarningQuota JournalRecipient LastFullBackup LastIncrementalBackup

v MailboxRetention v MountAtStartup v ProhibitSendQuota v ProhibitSendReceiveQuota v RetainDeletedItemsUntilBackup app.messaging.exchange.ExchangeProtocol v v v v AuthenticatedConnectionTimeout Banner DistinguishedName LoginType

v MaxCommandSize v MaxConnections v MaxConnectionsFromSingleIP v MaxConnectionsPerUser v PreAuthenticatedConnectionTimeout v v v v ProtocolName ProxyTargetPort UnencryptedOrTLSBindings X509CertificateName

app.messaging.exchange.ExchangePublicFolder v AgeLimit v UseDatabaseQuotaDefaults v UseDatabaseReplicationSchedule app.messaging.exchange.ExchangePublicFolderStore v AllowFileRestore v CopyEdbFilePath


Chapter 2. Application sensors

83

v v v v v v v v v v v v

CustomReferralServerList DeletedItemRetention IssueWarningQuota ItemRetentionPeriod LastFullBackup LastIncrementalBackup MaxItemSize MountAtStartup ProhibitPostQuota PublicFolderHierarchy ReplicationMessageSize ReplicationPeriod

v RetainDeletedItemsUntilBackup v UseCustomReferralList app.messaging.exchange.ExchangeServer v ActiveDirectoryDomainName v DistinguishedName v Domain v Edition v ErrorReportingEnabled v ProductID v Site app.messaging.exchange.ExchangeServerRole v RoleName app.messaging.exchange.ExchangeVirtualDirectory v DistinguishedName v ExternalURL v InternalURL v Path v VirtualDirectoryName app.messaging.exchange.MailboxServer v AutoDatabaseMountDial v ForcedDatabaseMountAfter v RedundantMachines app.messaging.exchange.OABVirtualDirectory v PollInterval app.messaging.exchange.OwaVirtualDirectory v v v v v v v ActiveSyncIntegrationEnabled AllAddressListsEnabled BasicAuthentication CalendarEnabled ChangePasswordEnabled ContactsEnabled DefaultDomain

84

Application Dependency Discovery Manager: Sensors

v v v v v v v v v v v v v v v v v v

DigestAuthentication FormsAuthentication JournalEnabled JunkEmailEnabled LogonFormat NotesEnabled OwaVersion PremiumClientEnabled PublicFoldersEnabled RecoverDeletedItemsEnabled RemindersAndNotificationsEnabled RulesEnabled SMimeEnabled SearchFoldersEnabled SignaturesEnabled SpellCheckerEnabled TasksEnabled ThemeSelectionEnabled

v UMIntegrationEnabled v WebSiteName v WindowsAuthentication app.messaging.exchange.ReceiveConnector v AnonymousUsersPermission v BasicAuthRequiresTLS v BasicAuthentication v ExchangeAuthentication v ExchangeLegacyServersPermission v v v v v ExchangeServersPermission ExchangeUsersPermission ExternalAuthoritative MutualAuthTLS PartnersPermission

v RemoteIPRanges v TLS v WindowsAuthentication app.messaging.exchange.SendConnector v AddressSpaces v DNSRoutingEnabled v DomainSecureEnabled v IsScoped v SmartHosts v UseExternalDNSRoutersEnabled app.messaging.exchange.TransportRule v Comments
Chapter 2. Application sensors

85

v Enabled v RulePriority v TransportRuleName

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. The sensor requires the credentials (user name and password) for the computer system 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 is running. The user must be a member of the local administrators group, and must be assigned Exchange View Only Administrator permissions on the Exchange 2007 Server. 3. Specify the access information (user name and password) that TADDM must use to access the Edge Transport server role. The Edge Transport server role is hosted on a dedicated computer and requires separate access information.

Configuring the collation.properties file entries


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

collation.properties file entries


The sensor uses the following entry in the collation.properties file: com.collation.discover.agent.exchange.command.timeout= 600000 The timeout (in milliseconds) for the WMI call to get the Exchange Server information. The default is 600000 milliseconds. Increase this value, when the WMI call takes a long time in large Exchange Server environments.

Troubleshooting the sensor


This topic describes common problems that occur with the Microsoft Exchange 2007 Server sensor and presents solutions for those problems.

The Exchange 2007 Server sensor does not start


Problem The Exchange 2007 Server sensor is not started. Solution For Microsoft Exchange Server 2007, ensure that the following services are started: 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)

86

Application Dependency Discovery Manager: Sensors

Run the services.msc program to check the status of the service or check the status by using Windows Task Manager.

Discovery returns a Stored-0 Exchange Server in the database message


Problem The Exchange 2007 Server sensor completes successfully with the following message: Stored-0 Exchange Server in the database. Solution No active Exchange Server is running on the target computer system. The possible 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 cluster administration program on the computer where the Exchange Server is installed 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 of the server roles. v Check the log file for the cause of the failure and verify that the gateway is configured correctly.

Invalid domain credentials used


Problem The sensor ends with the following error message:
CTJTD0835E Invalid domain credentials.

Solution Verify that in the Access List configuration, that the access information (user name and password) is correct. Access permission to the Active Directory domain on which the Exchange server is running, and not the local computer, must be granted.

Microsoft HyperV sensor


The Microsoft HyperV sensor discovers Microsoft Windows Server 2008 computers with the Hyper-V server role enabled. The discovery includes the host (also known as parent or root partition) and the virtualized guest computer systems (also known as child partitions) in a Hyper-V environment.

Sensor name that is used in the GUI and logs


Microsoft HyperV Sensor

Prerequisites
To discover the hypervisor and the virtualized guest systems, the hypervisor must be running with Microsoft Windows Server 2008 x64 Edition in the root (parent) partition.

Security issues
The TADDM service account on the target Hyper-V system, must be able to run the wmic command to query the Windows Management Instrumentation (WMI) interface.

Chapter 2. Application sensors

87

Enter the following command on one line, from the command-line interface of the target host system (parent partition) to verify:
wmic /namespace:\\root\virtualization path Msvm_VirtualSystemSettingData get SystemName, BaseBoardSerialNumber, ElementName

Limitations
The sensor supports Microsoft Windows 2008 x64 with Hyper-V enabled. The sensor does not support Microsoft Hyper-V Server 2008.

Model objects with associated attributes


The Microsoft HyperV sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about Microsoft Windows 2008 based computers with Microsoft Hyper-V Role enabled in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. sys.ComputerSystem The following attribute is associated with the host running the Hyper-V software: v ChildSystem (host) sys.ComputerSystem The following attributes are associated with the discovered objects that are virtualized on the host: v HostSystem v IsVMIDanLPAR v Manufacturer v v v v v MemorySize Model Name NumCPUs SerialNumber

v SystemBoardUUID v UUID v Virtual app.AppServer v Host v MajorVersion v ProductName v VendorName v VersionString

Configuring the sensor


Before running a discovery, you must configure the sensor.

88

Application Dependency Discovery Manager: Sensors

The Microsoft HyperV sensor requires a Level 2 discovery of the target host (parent partition) based on Microsoft Windows 2008 x64. Create an access list entry for Computer System (Windows) to discover the computers running Windows Server 2008 with Hyper-V.

Troubleshooting the sensor


This topic describes common problems that occur with the Microsoft HyperV sensor and presents solutions for those problems.

HyperV sensor is not running


Problem The HyperV sensor is not running. Solution Verify that the WindowsComputerSystemSensor is enabled in the discovery profile. Include in the scope one of the following options for the target Hyper-V host (parent partition): v Host name v Range (start and end IP addresses) v Subnet (IP address of the subnet mask) Verify that the WindowsComputerSystemSensor discovery of the target hypervisor host (parent partition) completes successfully. If there is a failure during the WindowsComputerSystemSensor discovery, then the HyperV sensor cannot start. Resolve the problems encountered by the WindowsComputerSystemSensor. Open the MicrosoftHyperVSensor-<ip_address>.log and search for: Microsoft HyperV sensor starting. Fix any errors reported.

Guest computer systems are not displayed


Problem The HyperV sensor ran, but where are the guests located in the Data Management Portal after a discovery? Solution In the Discovered Components pane go to Inventory Summary > Computer Systems > Other Computer Systems, to find the Hyper-V guest systems (child partitions).

Microsoft IIS Web server sensor


The Microsoft IIS Web server sensor discovers Microsoft Internet Information Services (IIS) servers.

Sensor name that is used in the GUI and logs


IISWebServiceSensor

Prerequisites
Ensure that the following requirements are met: v Discovery of the computer system must succeed.

Chapter 2. Application sensors

89

v The gateway must have the IIS Manager installed. This method ensures that the COM classes are installed. These classes are required by the TaddmTool AdsiDump and AdsiEnum commands. v If IIS Manager is not present, install it using Add/Remove Programs in the Windows Control Panel. Select Windows components > Application Server > IIS > Install IIS Manager. v To discover IIS 7.0 servers, the IIS 6.0 Metabase Compatibility component must be installed on the server. To install, complete the following steps: 1. Click Start > Administrative Tools > Server Manager. 2. In the navigation pane, expand Roles, right-click Web Server (IIS), and then click Add Role Services. 3. In the Select Role Services pane, scroll down to IIS 6 Management Compatibility. 4. Select the IIS 6 Metabase Compatibility check box. 5. In the Select Role Services pane, click Next, and then click Install at the Confirm Installations Selections pane. 6. Click Close to exit the Add Role Services wizard. When the IIS 6.0 Metabase Compatibility component is not installed, errors are displayed in the log file and a deep discovery does not occur.

Model objects created


The sensor creates the following model objects: v app.ProcessPool v app.web.iis.IIsModule v app.web.iis.IIsParameter v app.web.iis.IIsWebServer v app.web.iis.IIsWebService v app.web.iis.IIsWebVirtualDir v sys.RuntimeProcess

Configuring the access list


This topic describes the access details that you require, depending on your configuration. There are no specific access requirements. This sensor can be run using the ComputerSystem access credentials used to discover the client.

Troubleshooting the sensor


This topic describes common problems that occur with the Microsoft IIS Web server sensor and presents solutions for those problems.

No Web server information discovered


Problem The sensor does not discover any Web server information. Solution If the Web server information is missing, check the logs to determine if the TaddmTool program AdsiDump and AdsiEnum commands succeeded or failed.

90

Application Dependency Discovery Manager: Sensors

Check whether the TaddmTool program QueryRegistry commands succeeded. 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 the second provides service-related information.

Web server is duplicated


Problem During discovery, duplicate IIS Web servers are found. This problem can occur when the IIS Web servers have been discovered with an earlier version of TADDM. Earlier releases of TADDM used port 0 as the default listening port. If the same servers are discovered using a different listening port, these servers are duplicated and they cannot be automatically merged. Solution Use an SQL statement to identify duplicate IIS Web servers in the database. The following statement can be run on one line, on DB2 or Oracle databases:
select cast(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_DISPLAYNAME from APPSRVR APPZ INNER JOIN APPSRVR APPN ON APPZ.contextip_x = APPN.contextip_x AND APPZ.jdoclassx = APPN.jdoclassx where APPZ.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 configuration items, see the "Discovery tasks" section in the TADDM User's Guide.

NFS sensor
The NFS sensor discovers Network File System (NFS) servers.

Sensor name that is used in the GUI and logs


NFSServerSensor

Model objects created


The sensor creates the following model objects: v sys.NFSExport v sys.NFSSAP v sys.NFSService v sys.ServiceAccessPoint

Oracle Application Server sensor


The Oracle Application Server sensor discovers Oracle Application Server servers.
Chapter 2. Application sensors

91

Sensor name that is used in the GUI and logs


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 Oracle Application 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 entry in the collation.properties file. v These files must have read privileges for the collation user.

Model objects created


The OracleAppAgent creates the following model objects: v app.AppConfig v app.ConfigFile.SoftwareContainer v app.j2ee.EJB v app.j2ee.EntityBean v v v v v app.j2ee.J2EEComponent app.j2ee.J2EEDeployedObject app.j2ee.J2EEModule app.j2ee.J2EEResource app.j2ee.JSP

92

Application Dependency Discovery Manager: Sensors

v v v v v v v v v v v v v v v v v v

app.j2ee.MessageDrivenBean app.j2ee.oracleapp.OracleAppCluster app.j2ee.oracleapp.OracleAppConnectorModule app.j2ee.oracleapp.OracleAppDomain app.j2ee.oracleapp.OracleAppEJBModule app.j2ee.oracleapp.OracleAppJ2EEApplication app.j2ee.oracleapp.OracleAppJ2EEServer app.j2ee.oracleapp.OracleAppJ2EEWebSite app.j2ee.oracleapp.OracleAppJDBCConnectionPool app.j2ee.oracleapp.OracleAppJDBCDataSource app.j2ee.oracleapp.OracleAppJDBCDriver app.j2ee.oracleapp.OracleAppJMSDestination app.j2ee.oracleapp.OracleAppJMSServer app.j2ee.oracleapp.OracleAppJSPContainer app.j2ee.oracleapp.OracleAppJTAResource app.j2ee.oracleapp.OracleAppProcessManager app.j2ee.oracleapp.OracleAppResourceAdapter app.j2ee.oracleapp.OracleAppServlet

v app.j2ee.oracleapp.OracleAppWebModule v app.j2ee.StatefulSessionBean v app.j2ee.StatelessSessionBean v v v v core.LogicalContent enums.StatusEnum net.BindAddress net.IpAddress

v sys.ComputerSystem The OracleAppOpmn creates the following model objects: v app.AppConfig v app.ConfigFile v app.j2ee.oracleapp.OracleAppCluster v app.j2ee.oracleapp.OracleAppProcessManager v app.web.oracleapp.OracleAppHTTPServer v core.LogicalContent v v v v enums.StatusEnum net.BindAddress net.IpAddress sys.ComputerSystem

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


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

Chapter 2. Application sensors

93

Add an entry to the access list for the system running the Oracle Application Server.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. com.collation.oracleapp.root.dir=lib/oracleapp The default value is lib/oracleapp. This property specifies the location of the Oracle Application Server libraries on the TADDM server. You can specify an absolute or relative path for the directory location. If the value for this property is a relative path directory, the relative path is appended to the $COLLATION_HOME path. com.collation.platform.os.ignoreLoopbackProcesses=true The default value is true, which means that the processes that are listening on loopback interfaces are ignored. Therefore, if a server is listening only on the loopback IP address (127.0.0.1), and not on any other externally available 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 listening ports are considered for discovery. You must set this property to true if you want to discover an Oracle Application Server or the WebLogic sensors. For example, if the WeblogicServerVersionSensor sensor tries to start using a local host address, this property must be set to true.

Troubleshooting the sensor


This topic describes common problems that occur with the Oracle Application Server sensor and presents solutions for those problems.

Sensor does not start


Problem The lsof program is not properly set up to return information about all processes. Solution Ensure that you discover a supported version of Oracle Application Server. The Oracle Application Sensor runs the opmnctl status command. Verify that the system user that is used for discovery has privileges to run this command. The following list describes other possible reasons why the sensor does not start: v The LiSt Open Files (lsof) program is not correctly set up to return information about all processes. One of the following requirements for running 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.ignoreLoopbackProcesses property in the $COLLATION_HOME/etc/collation.properties file is set to

94

Application Dependency Discovery Manager: Sensors

false. The value must be set to true for the sensor to start. A value of true specifies that the processes that are listening on loopback interfaces are to be ignored. v The Oracle Application Server libraries are not available on the TADDM server. Oracle Application Server libraries must be made available on the TADDM server. Use the following property to specify the location of these libraries: com.collation.oracleapp.root.dir=lib/oracleapp The default value for this property is lib/oracleapp. If the value for this property 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 the following two subdirectories: j2ee opmn The Oracle Application Server libraries can be copied, or mounted using the Network File System (NFS), from an existing Oracle Application Server 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


Problem Oracle Application Server discovery is not supported on all platforms. Solution Ensure that TADDM supports discovery of the Oracle Application Server on your operating system.

Sensor fails in remote server


Problem The sensor fails in the remote server with an Agent terminated after exceeding time limitnull error. TADDM cannot find the Oracle Application Server libraries. Solution Check the setting of the com.collation.oracleapp.root.dir property.

Chapter 2. Application sensors

95

Sensor fails when trying to run discoverOpmnctl() method


Problem The sensor fails when it tries to run the discoverOpmnctl() method. The path of the TADDM service account on the Oracle Application Server system does not include the bin directory of the Oracle Application Server or the user has no read/execute privileges to run the opmnctl status command. Solution Add the bin directory of the Oracle Application Server to the path of the TADDM service account on the Oracle Application Server system.

Sensor fails in remote server with Name not found error message in log file
Problem The sensor fails and the following error is displayed in the log file:
javax.naming.NameNotFoundException: oc4j:internal/ResourceFinder not found

Solution Add the IP address and host name of the Oracle Application Server to the /etc/hosts file on the TADDM server.

SAP CCMS server sensor


The SAP CCMS server sensor discovers SAP systems, SAP servers (ABAP and Java), and SAP components.

Sensor name that is used in the GUI and logs


CCMSServerSensor

Prerequisites
The SAP CCMS server sensor requires JCo libraries to function. For information about JCo libraries, see the topic Installing the SAP Java Connector (JCo) libraries. Depending on the specific application of SAP NetWeaver systems, you can use the SAP CCMS server sensor, the SAP SLD server sensor, or both to discover this system. SAP applications are installed on two different database schemas depending on the application, and each are accessed by their respective runtime environments. There is a runtime environment for Java instances (Java stack) and one for the Advanced Business Application Programming (ABAP) instances (ABAP stack): 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 based on both the ABAP and Java stacks.

Configuring the sensor


Before running a discovery, you must configure the sensor.

96

Application Dependency Discovery Manager: Sensors

Installing the SAP Java Connector (JCo) libraries


You must install the SAP Java Connector (JCo) libraries for the specific operating system. To install the JCo library files, complete the following steps, where operating_system represents AIX, Linux, Linuxs390x, Solaris, or Windows: 1. From the SAP Service Marketplace website, download the appropriate SAP JCo libraries. 2. Back up the following directory: $COLLATION_HOME/lib/JCo/operating_system. 3. Copy the following files from the downloaded package to the following directories: v librfccm.o to $COLLATION_HOME/lib/JCo/operating_system v libsapjcorfc.so to $COLLATION_HOME/lib/JCo/operating_system v sapjco.jar to $COLLATION_HOME/lib/JCo/operating_system/lib 4. Restart the TADDM server. Run the ldd command against the libraries to see the dependencies, and ensure that the dependencies are supported. The base operating system supports most of the dependencies. On the Linux operating system, the libstdc++-libc6.2-2.so.3 library might not be installed by default. In that case, you must install the Red Hat package compat-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 [Cant find library sapjcorfc (libsapjcorfc.so) in sun.boot.library.path or java.library.path sun.boot. library.path={full-path-list}

Configuring the access list


This topic describes the access details that you require, depending on your configuration. To configure the access list, complete the following steps: 1. Select Computer 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 authorizations mentioned in the following list) b. Password c. Client ID The following lists the authorizations that are required by the SAP user being used for CCMS sensor discovery. Grant all (*) privileges to the following authorization objects: S_RFC Authorization Check for RFC Access S_ADMI_FCD System Authorizations S_BTCH_ADM Background Processing: Background Administrator
Chapter 2. Application sensors

97

S_DATASET Authorization for file access S_LOG_COM Authorization to Execute Logical Operating System Commands S_RZL_ADM CC Control Station: System Administration S_XMI_LOG Internal Access Authorization for XMI Log S_XMI_PROD Authorization for External Management Interfaces (XMI)

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. com.collation.platform.os.ignoreLoopbackProcesses=true The default value is true, which means that the processes that are listening on loopback interfaces are ignored. Therefore, if a server is listening only on the loopback IP address (127.0.0.1), and not on any other externally available 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 listening ports are considered for discovery. You must set this property to true if you want to discover an Oracle Application Server or the WebLogic sensors. For example, if the WeblogicServerVersionSensor sensor tries to start using a local host address, this property must be set to true.

Troubleshooting the sensor


This topic describes common problems that occur with the SAP CCMS server sensor and presents solutions for those problems.

Sensor fails in remote server


Problem The following errors occur, which means that the class path does not contain the path for the sapjco.jar file:
Sensor failed in remote server: com/sap/mw/jco/JCO MSG_ERROR: java.lang.NoClassDefFoundError: com/sap/mw/jco/JCO

Solution The sapjco.jar file should be in the $COLLATION_HOME/ lib/JCo/lib directory, 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


Problem The following errors occur, which means that the sensor cannot find the libsapjcorfc.so library file in sun.boot.library.path or in java.library.path:

98

Application Dependency Discovery Manager: Sensors

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 [Cant find library sapjcorfc (libsapjcorfc.so) in sun.boot.library.path or java.library.path sun.boot.library.path={full-path-list}

Solution Ensure that the libsapjcorfc.so library file is in the $COLLATION_HOME/ lib/JCo/operating system (Linux, AIX, or Solaris) path. Also ensure that this path is present in the full-path-list for sun.boot.library.path that is mentioned in the preceding message. If the path is present, the problem might be due to library dependencies that have not been met. Run the ldd command against the libsapjcorfc.so library file to get a list of the library dependencies, and verify that your environment supports these dependencies.

No CCMS access list is provided for an IP address


Problem The 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. Solution If you provided the necessary access list credentials, verify the following items: v Ensure that the user ID meets the specified minimum authorization requirements. 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: {client- id}

You can also provide SAP_ALL authorization to the user and try to connect to the SAP ABAP server directly through the SAP GUI, if it is available.

SAP SLD server sensor


The SAP SLD server sensor discovers SAP systems, SAP servers (ABAP and Java), and SAP components.

Sensor name that is used in the GUI and logs


SLDServerSensor

Prerequisites
The SAP System Landscape Directory (SLD) server must be running.

Chapter 2. Application sensors

99

Depending on the specific application of SAP NetWeaver systems, you can use the SAP CCMS server sensor, the SAP SLD server sensor, or both to discover this system. SAP applications are installed on two different database schemas depending on the application, and each are accessed by their respective runtime environments. There is a runtime environment for Java instances (Java stack) and one for the Advanced Business Application Programming (ABAP) instances (ABAP stack): 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 based on both the ABAP and Java stacks.

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 role to the SAP account, and depending on your configuration, you might also need to assign the SAP_J2EE_ADMIN role to the SAP account.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. com.collation.discover.agent.SLDServerAgent.connectionTimeout=30 The default value is 30, which means 30 seconds. The value must be an integer. This property specifies the maximum amount of time (in seconds) to wait for the initial SLD connection test. Connection timeouts are recorded in the DiscoveryManager.log file. If these timeouts occur, increase the value of this property. The property can be scoped to a specific host name or IP address, as shown 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.platform.os.ignoreLoopbackProcesses=true The default value is true, which means that the processes that are listening on loopback interfaces are ignored. Therefore, if a server is listening only on the loopback IP address (127.0.0.1), and not on any other externally available 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 listening ports are considered for discovery.

100

Application Dependency Discovery Manager: Sensors

You must set this property to true if you want to discover an Oracle Application Server or the WebLogic sensors. For example, if the WeblogicServerVersionSensor sensor tries to start using a local host address, this property must be set to true. com.collation.discover.agent.SLD.PoolSize This property specifies the maximum number of connection pools to be maintained alive to an SLD server. These connections can be reused for additional requests. The default value is 16. com.collation.sudoCommand This property specifies the sudo command name. The default value is sudo.

Troubleshooting the sensor


This topic describes common problems that occur with the SAP SLD server sensor and presents solutions for those problems.

SLDServerAgent connection timeout errors


Problem SLDServerAgent connection timeout errors are found in the DiscoverManager.log file. Solution In the $COLLATION_HOME/etc/collation.properties file, increase the value of the com.collation.discover.agent.SLDServerAgent.connectionTimeout property until the connection is successful.

SMB server sensor


The SMB server sensor discovers Server Message Block (SMB) file servers.

Sensor name that is used in the GUI and logs


SMBServerSensor

Model objects created


The sensor creates the following model objects: v sys.ServiceAccessPoint v sys.SMBExport v sys.SMBSAP v sys.SMBService

Troubleshooting the sensor


This topic describes common problems that occur with the SMB server sensor and presents solutions for those problems.

Error message uncaught exception results when running a discovery


Problem The following message is displayed when running a discovery:
Uncaught exception invoking GetSystemInfo: System.NullReferenceException: Object reference not set to an instance of an object

Chapter 2. Application sensors

101

Solution This message indicates that there is a problem with Windows Management Instrumentation (WMI) service. See the Windows computer system sensor Troubleshooting the sensor topic for information about WMI problems and solutions.

SMS server sensor


The SMS server sensor discovers the Microsoft Systems Management Server (SMS).

Sensor name that is used in the GUI and logs


SMSServerSensor

Limitations
The sensor does not discover information about SMS Server client computer systems as CDM ComputerSystem instances but instead as CDM SMSCollectionClients instances. Therefore, the discovery of an SMS Server cannot be used in place of direct discovery of the hosts that are part of the SMS Server infrastructure.

Model objects created


The sensor creates the following model objects: v app.sms.SMSAdvertizements v v v v v app.sms.SMSCollections app.sms.SMSCollectionClients app.sms.SMSHierarchy app.sms.SMSPackage app.sms.SMSProgram

v app.sms.SMSQuery v app.sms.SMSReports v v v v v app.sms.SMSResource app.sms.SMSServerProcess app.sms.SMSSiteBoundaries app.sms.SMSSiteComponents app.sms.SMSSiteServer

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.SMSServerAgent.GetReports If set to true, SMS Report information is captured by the sensor and stored as instances of the CDM SMSReports class. The default value is false. com.collation.discover.agent.SMSServerAgent.GetQueries If set to true, SMS predefined queries are captured by the sensor and stored as instances of the CDM SMSQuery class. The default value is false.

102

Application Dependency Discovery Manager: Sensors

com.collation.discover.agent.SMSServerAgent.GetClients If set to true, information about SMS collection clients is captured by the sensor and stored as instances of the CSM SMSCollectionClients class. The default value is false. com.collation.discover.agent.SMSServerAgent.MaxNrClients The maximum number of clients about which information is captured by the sensor. The default value is 100.

SysImager sensor
The SysImager sensor discovers SystemImager High Performance Computing (HPC) clusters.

Sensor name that is used in the GUI and logs


SysImagerServerSensor and SysImagerNodeSensor

Prerequisites
The GenericComputerSystemSensor, along with prerequisite sensors, must be enabled in the discovery profile used for discovering the SysImager cluster.

Model objects created


The sensor creates the following model objects: v sys.hpc.cm.ConfigurationManagementCluster v v v v v sys.hpc.cm.ConfigurationManagementNode sys.hpc.cm.ConfigurationMangementNodeGroup sys.hpc.cm.ConfigurationManagementClusterConfigFile sys.hpc.cm.SysImagerNode sys.hpc.cm.SysImagerNodeImage

v sys.hpc.cm.SysImagerOverride

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the discovery profile


This topic describes how to configure the discovery profile. 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: masterServerNames The IP addresses or host names of SysImager master nodes. This property must be set to start the SysImager server sensor. 3. If appropriate, set some of the following attributes, or accept the default values. configFileLocation The location of the SysImager configuration file. The default value is /etc/systemimager/systemimager.conf.

Chapter 2. Application sensors

103

clusterXMLFileLocation The location of the SysImager cluster configuration file. The default value is /etc/systemimager/cluster.xml. clusterConfigCommand The command to display configuration information about the SysImager cluster. The default value is si_clusterconfig -g. lsImageCommand The command to display images of the SysImager cluster. The default value is si_lsimage -v. imagesDiscoveryMode This property is not used. overridesDiscoveryMode The 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. The default value is 1. overridesDiscoveryPattern The filename pattern for files under the overrides directory. The default value is "*". preInstallScriptsContent The depth of file capture of the scripts executed before install. 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. The default value is 1. postInstallScriptsContent The depth of file capture of the scripts executed after install. 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. The default value is 1. nodesScope The scope of the IP addresses to which the SysImager node sensors are restricted. doPingNodes Specifies whether ping sensors are run against discovered SysImager nodes.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. SysImagerServerSensor uses SysImager Server access entry. If this is not available, the sensor uses ComputerSystem access entry to access the SysImager server.

104

Application Dependency Discovery Manager: Sensors

SysImagerNodeSensor uses ComputerSystem access entry to access SysImager nodes.

Veritas cluster sensor


The Veritas cluster sensor discovers Veritas Cluster Servers. The sensor collects general information about the Veritas Cluster Server and the services that are installed on it. Services are organized in service groups and contain information about the resources that are used. The sensor can create relationships between the services and applications installed on a cluster.

Sensor name that is used in the GUI and logs


VeritasClusterSensor

Security issues
The user account for discovering Computer Systems is also used for running Veritas commands. By default, execute permission on the Veritas Cluster directory and commands is required. The sensor uses the following commands: v hastatus v haclus v v v v v hasys hares hagrp hatype hauser

Before running Veritas commands, a login to the cluster is performed on systems that support the Veritas halogin command. These are UNIX systems with VCS version 4.1 and higher. The sensor logs in using the user name and password from the High Availability Solutions access list entry. To specify that the sensor should use sudo when running Veritas Cluster Server commands on Linux or UNIX systems, configure the appropriate parameters in the collation.properties file. To run the commands without using the sudo command, the TADDM service account must be a member of the Veritas Admin Group on the target. You must configure sudo ndd with NOPASSWORD for the access user.

Model objects created


The sensor creates the following model objects: v app.ConfigFile v app.SoftwareInstallation v app.veritas.cluster.VCSCluster v app.veritas.cluster.VCSHADServer v app.veritas.cluster.VCSLocalServiceGroup
Chapter 2. Application sensors

105

v app.veritas.cluster.VCSResourceConfiguration v app.veritas.cluster.VCSServiceGroup v app.veritas.cluster.VCSSystem

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the discovery profile


This topic describes how to configure the discovery profile. The following VeritasClusterSensor attribute can be modified: discoveryMode The default value for the discoveryMode attribute is 1 (the sensor runs in lightweight 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.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. The following properties specify that the sensor uses sudo to elevate privileges when 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 the following examples: v com.collation.discover.agent.command.hastatus =sudo /opt/VRTSvcs/bin/ hastatus

106

Application Dependency Discovery Manager: Sensors

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 systems running that operating system; otherwise, specify the option only for the specific IP addresses where the sudo command is configured. You must configure sudo ndd with NOPASSWORD for the access user. On each target system for which privilege escalation is needed, configure the sudo command with the NOPASSWD option. Otherwise, your discovery hangs until the TADDM server times out.

Troubleshooting the sensor


This topic describes common problems that occur with the Veritas cluster sensor and presents solutions for those problems.

The sensor fails


Problem The VeritasClusterSensor sensor fails. Solution If 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 correct user name and password for the Veritas Cluster is used.

VMware Virtual Center server sensor


The VMware Virtual Center server sensor discovers VMware Virtual Center servers and the elements that are managed by the servers. VMware Virtual Center is now known as VMware vCenter Server.

Sensor name that is used in the GUI and logs


VirtualCenterSensor

Elements discovered by the sensor


The sensor discovers the following elements that are managed by the Virtual Center server: v Data centers in a virtual center v VMware clusters created in each data center v Memory resource pools v CPU resource pools v VMware ESX servers managed by a virtual center v Virtual computers on each managed VMware ESX server v Virtual switches and port groups in each virtual switch v Distributed virtual switches, uplinks, and port groups in each distributed virtual switch. v Data stores created in each data center

Chapter 2. Application sensors

107

VMware ESX servers, which are discovered by the VMware ESX and Virtual Center server sensors, are merged after the discovery. In the Discovery Management Console, a VM (virtual machine) is represented by a computer system icon that is blue and transparent. The Virtual Center server sensor uses the VMware API to discover data, and the VMware API collects the following data: v Attribute data that is required to match naming rules and to create a valid stand-alone VM instance v Certain basic information that the VMware ESX server provides through the vmware-cmd command v The attribute primaryMACAddress, which is required to reconcile the shallow virtual instance with any physical instance that can be discovered v 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 are managed 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 by the Virtual Center and ESX sensors are reconciled. The physical instances have a virtual 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. ESX servers with typical attributes for example, model are displayed. The Virtual Center 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 by the Virtual Center sensor. v Virtual Center and VM: The discovery scope contains Virtual Center servers and all virtual computers. The results display all the virtual computers, with all the physical, and virtual attributes set to true. The virtual computers are displayed in the Virtual Systems tab of the respective ESX server.

Prerequisites
The VMware Virtual Center server service is running on the target windows computer.

Security issues
To discover the VMware Virtual Center server, you must set read-only permissions for the TADDM service account. The service account must have administrator privileges.

Model objects with associated attributes


The VMware Virtual Center server sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about VMware Virtual Center resources in your IT environment.

108

Application Dependency Discovery Manager: Sensors

The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. net.IpInterface (for ESX server only) v Name v IpAddress net.L2Interface v Name (for ESX server only) v Index (for Virtual Machines) v HwAddress process.CPUResourcePool v Name v Label v Limit v Reservation v SharesLevel v SharesValue process.MemoryResourcePool v Name v Label v Limit v Reservation v SharesLevel v 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 NumCPUs v Parent sys.DNSResolveEntry (for ESX server only) v ServerIP v Parent sys.Memory v MemorySize v Parent sys.NFSFileSystem v serverName v MountPoint v Type v Capacity
Chapter 2. Application sensors

109

v v v v v

AvailableSpace MaxFileSize StorageExtent FileSystemBlockSize MaxBlocks

sys.unix.UnixFileSystem (for Virtual Machine File System) v MountPoint v Type v Capacity v v v v v AvailableSpace MaxFileSize StorageExtent FileSystemBlockSize MaxBlocks

sys.vmware.DataCenter v Name v Label v Parent v Systems v Clusters v VirtualSwitches sys.vmware.VirtualCenter v Name v Host v v v v UID VersionString ApiVersion Vendor

v BuildLevel v VirtualCenterPort v MaxDBConnections v ClientTimeoutNormal v ClientTimeoutLong v WebServiceHttpPort v WebServiceHttpsPort sys.vmware.VMWareCluster v Name v Label v DPMEnabled v v v v v DRSEnabled HAEnabled Parent RootMemoryResourcePool RootCPUResourcePool

110

Application Dependency Discovery Manager: Sensors

sys.vmware.VMWareDataStore v Name v Label v Type v DataStoreURL v v v v v v v Capacity FreeSpace IsAccessible AccessMode IsMultipleHostsAccess BasedOn DataCenter

sys.vmware.VmwareESX v OSName v OSVersion sys.vmware.VMWarePortGroup v ActiveUplinks v L2Interfaces v Name v Parent v StandbyUplinks v Uplinks sys.vmware.VmwareUnitaryComputerSystem v Name v v v v Fqdn ObjectType Manufacturer Model

v CPUSpeed v CPUType v LifecycleState v NumCPUs v MemorySize v v v v v AvailableMemoryForAllVMs CurrentMemoryForAllVMs SwapMemorySize ServiceConsoleMemorySize VmotionEnabled DataCenter Name MTU NumPorts NumPortsAvailable
Chapter 2. Application sensors

sys.vmware.VMWareVirtualSwitch v v v v v

111

v v v v v

ObjectType PortGroups Parent UplinkPortGroups Interfaces

sys.vmware.VMWareDVUplink v L2Interfaces v Name Multiple virtual machines, such as the following operating systems and virtual systems: sys.darwin.Darwin sys.darwin.DarwinUnitaryComputerSystem sys.dos.Dos sys.dos.DosUnitaryComputerSystem sys.freebsd.FreeBSD sys.freebsd.FreeBSDUnitaryComputerSystem sys.linux.Linux sys.linux.LinuxUnitaryComputerSystem sys.netware.Netware sys.netware.NetwareUnitaryComputerSystem sys.sun.Solaris sys.sun.SunSPARCUnitaryComputerSystem sys.windows.WindowsComputerSystem sys.windows.WindowsOperatingSystem The following attributes are associated with these model objects: v uuid v v v v v VMID OSName Fqdn (if VMware Tools are running on virtual machine) MemorySize NumCPUs

v FaultTolerance

Configuring the sensor


Before using the VMware Virtual Center server sensor, you must configure it.

Configuring the non-root user to run the sensor


You must add the users credentials to the Read-Only role by using the VMware Infrastructure Client for non-root users. By default, non-root users do not have permission to run the Virtual Center server sensor. To enable this function, for non-root users add the users credentials to the Read-Only role by using the VMware Infrastructure Client. For root users, do not do this task. To add a user to the Read-Only role, complete the following steps:

112

Application Dependency Discovery Manager: Sensors

1. From the VMware Infrastructure Client, log on to the VMware Virtual Center server using root credentials. 2. Click the Permissions tab. 3. Right-click in the Permissions pane and click Add Permissions. The Assign Permissions window is displayed. 4. In the Assigned Role area, select Read-Only from the list. 5. In the Users and Groups area, click Add. The Select Users window is displayed. 6. Select the non-root user that you want to include in this role. Click Add and click OK. 7. In the Assign Permissions window, click OK to apply the changes.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. To configure the access list, enter the following information: v To access the VMware Virtual Center server using an account with administrator privileges: 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 the VMware Virtual Center server. v To access the VMware Virtual Center server using an account with read-only privileges: 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 Tivoli Monitoring environment. This method grants access to the Virtual Center server only and does not grant access to the host computer system. In the discovery profile include the VMware Virtual Center server sensor and the IBM Tivoli Monitoring Scope sensor.

Troubleshooting the sensor


This topic describes common problems that occur with the VMware Virtual Center server sensor and presents solutions for those problems.

Serial number and System ID are blank in the Details panel of the VMware ESX server
Problem The attributes Serial number and System ID are blank in the Details panel of the VMware ESX server. The attributes for the file system are not discovered. Solution The attributes are not displayed because the information is not available from the API. For the L2Interface layer, only the name and hardware addresses are collected. Verify that the ESX server and Virtual Center server are included in the discovery scope. Check the credentials, to ensure that the correct permissions are used for accessing the ESX server and Virtual Center server, and run the discovery again.
Chapter 2. Application sensors

113

The sensor fails with a timeout error


Problem If the Virtual Center server is managing many ESX hosts and virtual computers then the sensor can fail with a timeout error message, An error occurred. Sensor timed out. Solution In the etc/collation.properties file, increase the value for the sensor to run, where value is the number of milliseconds allowed for the sensor to run:
com.collation.discover.agent.VirtualCenterSensor.timeout=value

The default value is 3600000 .

Elements managed by the VMware Virtual Center server are not discovered
Problem Elements are not discovered on VMware vCenter Server Version 4.1 running on Microsoft Windows Server 2003. The following error messages exist: v The VirtualCenterServer log contains:
AxisFault faultCode: {http://xml.apache.org/axis/}HTTP faultSubcode: faultString: (503)Service Unavailable faultActor: faultNode: faultDetail: {}:return code: 503 503 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 VMware Virtual Center server shows many TCP/IP Ports are left open in a LAST_ACK state. Solution The behavior occurs because ephemeral ports, temporary ports that are used for client server communications, are not closed upon use. Ephemeral ports are limited to a range of ports and are only valid for the duration of the connection. In this case, on certain Microsoft Windows operating systems, certain connections leave the ports in a LAST_ACK state on the Virtual Center server. The range of ports can be exhausted after a time and when this situation happens, connectivity can fail until a port is freed. To prevent this event occurring, go to the Microsoft website at http://support.microsoft.com and search for KB979230. You can then download and install the fix.

WebLogic sensor
The WebLogic sensor discovers Oracle WebLogic Server application servers and WebLogic Server version information.

114

Application Dependency Discovery Manager: Sensors

The JAR files of all releases of WebLogic 9 can be used to discover all releases of WebLogic 9 and 10.

Sensor name that is used in the GUI and logs


v WeblogicSensor v WeblogicSensor2 v WeblogicServerVersionSensor

Prerequisites
The WeblogicSensor sensor requires additional JAR files that are part of the Oracle WebLogic Server installation. You must copy these JAR files to the following directories on the TADDM server: v For Linux, Solaris, 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 create in the $COLLATION_HOME/lib/weblogic/ directory. However, each directory must be configured in the WeblogicVersionSensor.xml file.

Security issues
The TADDM server requires the WebLogic system login name and the password that is used to log in to the WebLogic Product Console.

Limitations
TADDM does not support WebLogic discovery with the WebLogic sensor when using SSL. The WebLogic sensor must not be run with the WebLogic SSH pluggable sensors in the same discovery. Do not enable the WebLogic sensor and the WebLogic SSH pluggable sensors in the same discovery profile.

Model objects created


The sensor creates the following model objects: v app.AppConfig v app.AppServer v v v v v app.ConfigFile app.j2ee.weblogic.WebLogicServer app.j2ee.J2EEComponent app.j2ee.J2EEDeployedObject app.j2ee.J2EEDomain
Chapter 2. Application sensors

115

v v v v v v v v v v v v v v v v v v

app.j2ee.J2EEModule app.j2ee.J2EEResource app.j2ee.weblogic.WebLogicCluster app.j2ee.weblogic.WebLogicConnector app.j2ee.weblogic.WebLogicConnectorModule app.j2ee.weblogic.WebLogicDomain app.j2ee.weblogic.WebLogicEJBModule app.j2ee.weblogic.WebLogicJ2EEApplication app.j2ee.weblogic.WebLogicJDBCConnectionPool app.j2ee.weblogic.WebLogicJDBCDataSource app.j2ee.weblogic.WebLogicJDBCDriver app.j2ee.weblogic.WebLogicJDBCMultiPool app.j2ee.weblogic.WebLogicJDBCTxDataSource app.j2ee.weblogic.WebLogicJMSServer app.j2ee.weblogic.WebLogicJMSStore app.j2ee.weblogic.WebLogicJTA app.j2ee.weblogic.WebLogicMachine app.j2ee.weblogic.WebLogicSSLSettings

v app.j2ee.weblogic.WebLogicServer v app.j2ee.weblogic.WebLogicServlet v app.j2ee.weblogic.WebLogicVirtualHost v v v v app.j2ee.weblogic.WebLogicWebContainer app.j2ee.weblogic.WebLogicWebModule app.ProcessPool app.SoftwareContainer

v app.web.WebVirtualHost

Configuring the sensor


Before using the WebLogic sensor, you must configure it.

Copying JAR files to the TADDM server


You must copy additional JAR files that are part of the Oracle WebLogic Server installation to the TADDM server. Before starting a discovery, copy the required JAR files for your WebLogic version to the $COLLATION_HOME/lib/weblogic/$VERSION_DIR/ directory:
Table 7. Required WebLogic JAR files WebLogic version WebLogic version 9 (all releases) WebLogic version 10.0 through 10.2 WebLogic version 10.3 Required JAR files v $WEBLOGIC_HOME/server/lib/weblogic.jar v $WEBLOGIC_HOME/server/lib/webservices.jar v $WEBLOGIC_HOME/server/lib/wljmxclient.jar

v $WEBLOGIC_HOME/server/lib/wlfullclient.jar

Make sure the user used to run TADDM has read access to the copied JAR files.

116

Application Dependency Discovery Manager: Sensors

Creating a wlfullclient.jar for the WebLogic sensor


You must create a wlfullclient.jar file for a client application. This JAR file is required for WebLogic version 10.3, or later. To create a wlfullclient.jar file for the WebLogic sensor, complete the following steps: 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 the WL_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 file


You 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 JDK using XML tags. In this example, the following directories and JDK pairs are configured: v The JAR files from the lib/weblogic/10.0 directory are paired with JDK 1.5.0. v The JAR files from the lib/weblogic/9.0 directory are paired with JDK 1.5.0. The <entry> tag configures the directory name used to store the WebLogic JAR files. The WebLogic JAR files must be located in the lib/weblogic directory. Similarly, the <jdk> tag configures the version of the Java JDK in use. The only version of JDK that is valid is 1.5.0. If the WeblogicServerVersionSensor sensor does not recognize 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>

Chapter 2. Application sensors

117

</item> </weblogicClassPath> <!--<weblogicClassPathDefault> <entry>10.0</entry> <weblogicVersion>10</weblogicVersion> <jdk>1.5.0</jdk> </weblogicClassPathDefault>--> </configuration> </SensorPlugin>

In the sample, the WeblogicServerVersionSensor sensor uses JAR files from the lib/weblogic/10.0 directory with JDK 1.5.0 and assumes that WebLogic Server 10.x is running.

Editing the WeblogicSensor2.xml file


You 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 multiple interfaces on the Domain Admin Server. In this case, the value of DOMAIN_IP and DOMAIN_PORT is used instead of IP_OF_FIRST_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING and IP_OF_SECOND_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING.

Copying JAR files to discover older versions of WebLogic application servers


To discover servers running older versions of WebLogic, copy the JAR files to the TADDM server.

118

Application Dependency Discovery Manager: Sensors

In most cases, if you have the JAR files from the current version of WebLogic, you can also discover servers running older versions of WebLogic. When this method does 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.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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: a. User name b. Password Ensure the WebLogic user you add to the access list has the following information: v Administrator privileges v Password

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the WebLogic sensor uses. com.collation.agent.weblogic.domainsconfiguration Used when the WebLogic server uses multiple interfaces on the Domain Admin Server (domain_ipX:domain_portX is used instead of listen_ipN:listen_portN). The syntax of the property is as follows:
com.collation.agent.weblogic.domainsconfiguration domain_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.protocols By default, this property is disabled, and the T3 protocol is used. If you uncomment this property, you can specify the list of protocols (separated by commas) to be used by the WebLogic sensors, as shown in the following example:
com.collation.agent.weblogic.protocols=t3,http

In this example, the T3 protocol is the first protocol that is tried. If this protocol fails, the HTTP protocol is used. If you want to use the HTTP protocol to connect to a WebLogic server instance, you must enable HTTP tunneling for that instance using the WebLogic Console.
Chapter 2. Application sensors

119

The only valid values are t3 and http. If you code an incorrect value, such as a value with typographical errors, the WebLogic server cannot process the request properly and might stop. com.collation.platform.os.ignoreLoopbackProcesses=true The default value is true, which means that the processes that are listening on loopback interfaces are ignored. Therefore, if a server is listening only on the loopback IP address (127.0.0.1), and not on any other externally available 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 listening ports are considered for discovery. You must set this property to true if you want to discover an Oracle Application Server or the WebLogic sensors. For example, if the WeblogicServerVersionSensor sensor tries to start using a local host address, this property must be set to true.

Troubleshooting the sensor


This topic describes common problems that occur with the WebLogic sensor and presents solutions for those problems.

WebLogic sensor does not start


Problem The WebLogic sensor does not start. Solution Perform 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/VERSION directory. 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 and that the WebLogic server uses the Java Management Extensions (JMX) communication protocol that is supported by TADDM. Configure the com.collation.agent.weblogic.protocols property in the collation.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 following property in the collation.properties file to true:
com.collation.platform.os.ignoreLoopbackProcesses=true

WebLogic sensor fails


Problem The WeblogicServerVersion sensor fails. Solution Copy the required WebLogic JAR files to the TADDM installation (see Configuring the sensor for details). Alternatively, the authentication information is missing or incorrect.

120

Application Dependency Discovery Manager: Sensors

Sensor fails in remote server


Problem The following error is in the local-anchor*.log, which typically means that the WebLogic security authentication information is missing or incorrect:
Sensor failed in remote server: An error occurred in the null sensor.

Solution Ensure that you have the correct security authentication information. The TADDM server requires the WebLogic system login name and the password that is used to log in to the WebLogic Product Console.

Message states that nothing exists to be discovered


Problem The WebLogic sensor runs and completes successfully with the following message:
There was nothing to be discovered.

Solution This message occurs when you are discovering a WebLogic Application Server. Although this situation is not a problem, ensure that the WebLogic sensor runs against the WebLogic Admin Server.

Sensor fails with WebLogic 10.x


Problem The WeblogicServerVersion sensor fails only with WebLogic 10.x. Solution WeblogicVersionSensor uses an external command to identify the version of WebLogic. On some WebLogic 10.x installations, this command returns an unexpected empty string which causes the WeblogicVersionSensor to fail. 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 Administration Server


Problem While attempting discovery of a WebLogic Administration Server, the WebLogic sensor fails as a result of a non-functioning DNS. Solution Discoveries involving the sensors related to WebLogic Administration Servers must have working DNS. As a workaround, change com.collation.platform.os.disableRemoteHostDNSLookups to true, and ensure that the TADDM server always has the correct DNS search path.

WebLogic sensor fails due to timeout


Problem The WebLogic sensor fails due to timeout. Solution Increase value of the com.collation.discover.agent.NAME timeout property in the collation.properties file, where NAME represents the name of the
Chapter 2. Application sensors

121

sensor that is configured in the XML file in the $COLLATION_HOME/etc/ discover-sensors directory. The following examples show how to code this property:
com.collation.discover.agent.WeblogicSensor2.timeout=7200000 com.collation.discover.agent.WeblogicSensor.timeout=7200000

WebLogic sensor fails after migration


Problem The WebLogic sensor fails after migration. Solution Ensure that you run the $COLLATION_HOME/bin/template-upgrade.sh script.

Sensor fails due to T3 problem


Problem The WeblogicServerVersion sensor fails due to inaccessible T3 protocol. Solution In some installations, the T3 protocol might be blocked. In this case, configure the WebLogic Servers to use the http protocol, and configure the WeblogicSensors to use http as well. For example:
com.collation.agent.weblogic.protocols=t3,http

WeblogicServerVersion fails due to timeout when issuing a version command


Problem The weblogicServerVersion times out while issuing the version command. The problem can be due to the port being blocked by the firewall. The following example shows port number 6079 is blocked by a firewall:
2009-09-09 12:29:38,802 DiscoverManager DiscoverWorker-11 WeblogicServerVersionSensor-169.70.70.100-6079 DEBUG j2ee.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/wljm xclient.jar -Duser.language=en -Duser.region=US weblogic.Admin -url t3://169.70.70.100:6079 -username confadmin -password XXX VERSION 2009-09-09 12:29:39,133 DiscoverManager DiscoverWorker-11 WeblogicServerVersionSensor-169.70.70.100-6079 DEBUG util.OsCommand - Command executed, capturing output 2009-09-09 12:33:03,526 DiscoverManager DISCOVER_SENSOR_CLEANUP_DiscoverWorker-11 WeblogicServerVersionSensor-169.70.70.100-6079 DEBUG j2ee.WeblogicServerVersionAgent - JavaCommand error java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:231) at java.lang.Thread.join(Thread.java:680) at com.collation.platform.util.OsCommand.execute(OsCommand.java:411)

Solution This sensor uses a protocol other than SSH for host access, the appropriate port needs to be open between the TADDM server and the target. In cases when a firewall prevents direct access from the discovery server to certain hosts or devices, you can specify a computer system that does have access to the hosts or devices to be an anchor host.

122

Application Dependency Discovery Manager: Sensors

WebLogic SSH sensor


The WebLogic SSH sensor parses WebLogic Server configuration files and uses that information to discover WebLogic Server components and their configuration. The set of pluggable sensors can connect to the target system using SSH, WMI, and other protocols that are supported by the generic computer system sensor.

Sensor name that is used in the GUI and logs


v v v v WeblogicLauncherSensor WeblogicApplicationSensor WeblogicDomainSensor WeblogicServerSensor

Security issues
The WebLogic pluggable sensors require computer system credentials or WebLogic credentials.

Limitations
For a discovery to run, the WebLogic pluggable sensors must have access to the domain configuration files. The location of the domain configuration directory can be 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 started with the following argument:
-Dweblogic.RootDirectory=domain_directory

v The WebLogic server is started as a UNIX process, and the location of the domain configuration directory is set as one of the following process environment variables: DOMAIN_HOME LONG_DOMAIN_HOME PWD OLD_PWD OLDPWD v The WebLogic server is started as a Windows or UNIX process, and the process contains a variable with the path to the domains subdirectory. All domains are in the user_project_directory/domains/domain_name directory. A search for the configuration file is carried out in the directory and all sub directories defined in the 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 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 process contains a variable with the path to the servers subdirectory. The servers
Chapter 2. Application sensors

123

directory is located in the Domain home directory. A search for the configuration file is carried out in the directory and all sub directories defined in the path for the 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 are searched 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 process contains a variable with the path to the user_project subdirectory. The user_projects directory is the default directory containing WebLogic projects. A search for the configuration file is carried out in the directory and all sub directories 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 are searched 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. See the topic Configuring the sensor for details. On Windows, the WebLogic launcher sensor normally does not start if the WebLogic process is not started as a Windows service. It might start correctly if the required environment variables have been set up. On UNIX, when a non-typical installation has been performed, it might be necessary to set configuration information in the WebLogic launcher sensor configuration file. For the WebLogic managed server, the WebLogic process name must be called with the following argument:
-Dweblogic.management.server=server_name

The WebLogic SSH pluggable sensors must not be run with the WebLogic sensor in the same discovery, so you must not enable the WebLogic SSH pluggable sensors and the WebLogic sensor in the same discovery profile.

Model objects created


The sensor creates the following model objects: v app.AppConfig v app.AppServer v v v v app.ConfigFile app.j2ee.weblogic.WebLogicServer app.j2ee.J2EEComponent app.j2ee.J2EEDeployedObject

124

Application Dependency Discovery Manager: Sensors

v v v v v v v v v v v v v v v v v v

app.j2ee.J2EEDomain app.j2ee.J2EEModule app.j2ee.J2EEResource app.j2ee.weblogic.WebLogicCluster app.j2ee.weblogic.WebLogicConnector app.j2ee.weblogic.WebLogicConnectorModule app.j2ee.weblogic.WebLogicDomain app.j2ee.weblogic.WebLogicEJBModule app.j2ee.weblogic.WebLogicJ2EEApplication app.j2ee.weblogic.WebLogicJDBCConnectionPool app.j2ee.weblogic.WebLogicJDBCDataSource app.j2ee.weblogic.WebLogicJDBCDriver app.j2ee.weblogic.WebLogicJDBCMultiPool app.j2ee.weblogic.WebLogicJDBCTxDataSource app.j2ee.weblogic.WebLogicJMSServer app.j2ee.weblogic.WebLogicJMSStore app.j2ee.weblogic.WebLogicJTA app.j2ee.weblogic.WebLogicMachine

v app.j2ee.weblogic.WebLogicSSLSettings v app.j2ee.weblogic.WebLogicServer v app.j2ee.weblogic.WebLogicServlet v v v v app.j2ee.weblogic.WebLogicVirtualHost app.j2ee.weblogic.WebLogicWebContainer app.j2ee.weblogic.WebLogicWebModule app.ProcessPool

v app.SoftwareContainer v app.web.WebVirtualHost

Resources that the sensor discovers


This topic describes the resources that can be discovered by the WebLogic pluggable 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 XML configuration files.

WebLogic launcher sensor


The WebLogic launcher sensor is started, after the generic server sensor, using a pluggable template, configured in plugin.xml. It discovers most typical WebLogic installations, and can be manually configured if necessary. It v v v v discovers the following information: The path to the directory containing configuration files for the domain. The version of WebLogic installed on the target machine. Whether the target is an administration server or a managed server. The listen IP and port of the administration server.

v Basic information about the structure of the WebLogic domain and servers.
Chapter 2. Application sensors

125

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 server v WebLogic server sensor for administration server

WebLogic domain sensor


The WebLogic domain sensor discovers information about the full WebLogic domain. The following information (available in XML configuration files), is discovered: v Domain details v Machine details v Cluster details v SSL settings v v v v JTA JDBC connection pool JDBC data source JDBC multi pool

v JMS server v 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 server and basic information about the WebLogic domain. The following information (available in XML configuration files), is discovered: v Server details v JDBC connection pool v JDBC data source v JDBC multi pool v 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 on the WebLogic server and the WebLogic applications deployed on the WebLogic domain.

126

Application Dependency Discovery Manager: Sensors

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 support


The WebLogic SSH sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. For script-based discovery, you must configure the WeblogicLauncherSensor sensor to use script-based discovery. See the TADDM Administrator's Guide for information about configuring for script-based discovery. The following sensors, which are descendants of the WeblogicLauncherSensor sensor, require no configuration: v WeblogicApplicationSensor v WeblogicDomainSensor v WeblogicServerSensor

Limitations
The last modification dates of collected configuration files are not available. Application descriptor discovery is not supported.

Configuring the sensor


The WebLogic pluggable sensors can be configured by editing the plugin.xml configuration file. You can perform WebLogic-specific configuration by editing the <configuration> element for the following WebLogic pluggable sensors: v WebLogic launcher sensor v WebLogic server sensor v 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.0 directory. Within the <configuration> element, you can configure information about the configuration directory for each domain. Place the information for each domain in a separate <item> element. For each domain, you can configure the following elements: <configDirectory> The domain configuration directory.

Chapter 2. Application sensors

127

<adminServer> Contains information about the IP address and port number on which the WebLogic administration console is listening. The following elements are used to specify this information: <listenAddress> The IP address on which the WebLogic administration console is listening. <listenPort> The port number on which the WebLogic administration console is listening. 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 starting the 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.0 directory. In the plugin.xml configuration file, you can configure the following elements: <discoverAppDescriptors> Specifies if the discovery of application descriptors is enabled. The discovery of application descriptors can be time consuming because the descriptors are defined in additional configuration files on the remote machine 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 are defined in additional configuration files on the remote machine where WebLogic is installed. The following sample configuration file displays the typical usage of the <discoverAppDescriptors> and <discoverJdbcDetails> elements:
<configuration className="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicServerConfigurationItem"> <discoverAppDescriptors>true</discoverAppDescriptors> <discoverJdbcDetails>true</discoverJdbcDetails> </configuration>

128

Application Dependency Discovery Manager: Sensors

WebLogic application sensor configuration


The plugin.xml file for the WebLogic application sensor is located in the following directory:
$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. The discovery of application/module descriptors (J2EE descriptors) can be time consuming because the descriptors are defined in additional configuration files on the remote machine where WebLogic is installed. The following sample configuration file displays the typical usage of the <discoverApplicationDetails> element:
<configuration className="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicApplicationConfigurationItem"> <discoverApplicationDetails>true</discoverApplicationDetails> </configuration>

Troubleshooting the sensor


This topic describes common problems that occur with the WebLogic SSH sensor and presents solutions for those problems.

The sensor fails with a Domain config dir not found error
Problem The Domain configuration directory cannot be found. Check the ps output for the process and verify in the limitations section that the configuration is supported. Solution Use 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 WebLogic launcher sensor configuration. See the topic Configuring the sensor for details.

WeblogicLauncherSensor fails because the ps output is cut on HP-UX


The topic describes common problems that occur with the WebLogic SSH sensor, and presents solutions for those problems. Problem WeblogicLauncherSensor fails when trying to discover WebLogic on HP-UX and the following error message can be found in the sensor log file: "Cannot find server name in command line: <COMMAND LINE>". A possible reason of this failure is the cut of a ps command output, which is a documented behavior of HP-UX. Solution

Chapter 2. Application sensors

129

1. Set com.ibm.cdb.discover.WeblogicLauncherSensor.parseConfigXml=true in 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).

130

Application Dependency Discovery Manager: Sensors

Chapter 3. Database sensors


Database sensors discover the databases that are used in the environment.

IBM DB2 sensor


The IBM DB2 sensor discovers IBM DB2 Universal Database (UDB) servers.

Sensor name that is used in the GUI and logs


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 DB2 utility programs on the remote system: v dist/bin/db2find.sh v dist/bin/db2findschema.sh The scripts run the following DB2 commands: db2 db2ilist List instances command db2set DB2 profile registry command db2licm License management tool command db2level Show DB2 service level command db2 get dbm cfg Command line processor invocation command

Limitations
During discovery, the sensor temporarily changes the code page of the db2 command-line tool. The sensor reverts the code page to its original setting after the discovery is completed. Incorrect characters can be discovered if you are using a 32-bit DB2 on a 64-bit Windows operating system. This character encoding problem is due to a limitation of the 64-bit Windows operating system, which hides commands such as chcp from 32-bit applications such as the db2cmd.exe program.
Copyright IBM Corp. 2008, 2012

131

If more than one version of DB2 is installed on the same Windows computer system, the sensor cannot discover the IBM DB2 Universal Database (UDB) server. TADDM runs the topology building process on a periodic basis. Until the topology building process is complete after a discovery, the database names that are displayed for remote systems might not be unique. After the topology build process is complete, the database name contains both the port number and the IP address of the remote database.

Model objects created


The sensor creates the following model objects: v app.db.db2.Db2AdminServer v app.db.db2.Db2Alias v app.db.db2.Db2BufferPool v v v v v v v app.db.db2.Db2ConfigValue app.db.db2.Db2Container app.db.db2.Db2Database app.db.db2.Db2DatabaseConfigValue app.db.db2.Db2Instance app.db.db2.Db2InstanceConfigValue app.db.db2.Db2Module

v app.db.db2.Db2Schema v app.db.db2.Db2Server v v v v app.db.db2.Db2ServerProcess app.db.db2.Db2System app.db.db2.Db2SystemConfigValue app.db.db2.Db2TableSpace

Asynchronous and script-based discovery support


The IBM DB2 sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. See the TADDM Administrator's Guide for information about configuring for 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.

Configuring the sensor


Before running a discovery, you must configure the sensor.

132

Application Dependency Discovery Manager: Sensors

Configuring the access list


This topic describes the access details that you require, depending on your configuration. To 1. 2. 3. configure the access list, complete the following steps: Select Database as the Component Type. Select DB2 as the Vendor. Specify the following required information: a. User name b. Password The DB2 UNIX sensor uses credentials from the access list in the following sequence: 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 user credentials from the access list must belong to the DB2 administration group for all DB2 installations.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the IBM DB2 sensor uses. The DB2 sensor that is running on a Windows system (Db2WindowsSensor) uses the 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) that the DB2 sensor can run 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 command to run on the Windows gateway. If the value of the Db2WindowsAgent.sshSessionCommandTimeout property is less than the value of the com.collation.SshSessionCommandTimout property, the com.collation.SshSessionCommandTimout value is used. v Less than the value of the com.collation.discover.DefaultAgentTimeout property. Because the sensor can stop before it finishes collecting information, the value of the com.collation.discover.DefaultAgentTimeout property should be greater. If needed, you can change the values of the com.collation.SshSessionCommandTimeout and com.collation.discover.DefaultAgentTimeout properties.

Chapter 3. Database sensors

133

For the following properties, you can also specify an IP address, as shown in the following example:
com.collation.discover.agent.DB2Agent.db2findscript.1.2.3.4=sudo

com.collation.discover.agent.DB2Agent.db2findscript=sudo This value enables access to the dist/bin/db2find.sh script executed during the discovery using the sudo command. com.collation.discover.agent.DB2Agent.db2findschemascript=sudo This value enables access to the db2findschema.sh script executed during the discovery using the sudo command. com.collation.discover.agent.DB2Agent.systemcommand=sudo This value enables access to the system command executed during the discovery using the sudo command.

Troubleshooting the sensor


This topic describes common problems that occur with the IBM DB2 sensor and presents solutions for those problems.

The DB2 sensor fails during discovery


Problem The DB2 sensor is timing out during the discovery run. Solution Increase the com.collation.discover.agent.Db2WindowsAgent.sshSession CommandTimeout property in the collation.properties file. Also, you could increase the com.collation.discover.DefaultAgentTimeout property to ensure that it is always larger than the com.collation.discover.agent.Db2WindowsAgent.sshSession CommandTimeout property.

Dependencies exist between a database and a business application but are not detected
Problem Although dependencies exist between a database and a business application, no dependency is detected because the user that is defined in the discovery access list for DB2 is not the instance owner. Solution For discovery processes to find the DB2 commands to list databases, the user that is defined in the discovery access list for DB2 must source the DB2 profile in the user profile.

The Details panel for a discovered DB2 component is blank


Problem When performing a discovery, the Details panel under the License tab for a discovered DB2 component is blank. This problem affects all levels of TADDM, on all platforms. Solution On UNIX and Linux, the db2licm executable routine must have the proper permissions for the user specified in the Discovery Management Console as connecting to the database. To retrieve the license information, the Discovery user must also have the primary group of the DB2 instance owner in its group list.

134

Application Dependency Discovery Manager: Sensors

CTJTP1127E The copy command fails during a DB2 discovery


Problem The following error message is displayed in the Discovery Management Console during a discovery of DB2:
CTJDT0234E The following error occurred:CTJDT0235E The following error occurred 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 error occurred 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 copy command 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

Solution This error message appears because the secure copy (scp) command is not in the PATH of the user ID that is being used by the remote computer system 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 sure that you include the full path to the scp command in the PATH environment variable.

The DB2 sensor fails with error CTJTD0234E


Problem The DB2 sensor fails with error CTJTD0234E and the following error message:
Attribute not set: instances

Solution This message is displayed because the PATH variable does not include the DB2 commands needed by the db2find.sh script.
Chapter 3. Database sensors

135

To correct this problem, add the required paths to the following entry in the collation.properties file:
com.collation.discover.agent.path.system_uname

IBM Informix sensor


The IBM Informix sensor discovers IBM Informix Dynamic Servers.

Sensor name that is used in the GUI and logs


Informix

Prerequisites
The IBM Informix JDBC driver must be installed on the IBM Informix Dynamic Server.

Limitations
The Informix Dynamic Server must be configured with the minimum requirement for discovery. Add the discovery service account to the group Informix on the Informix Dynamic Server.

Model objects with associated attributes


The IBM Informix sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about IBM Informix Dynamic Server resources in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. app.db.ids.IDSAlias v AliasName v Parent v Protocol v ServiceName app.db.ids.IDSBufferPool v BufferPoolID v NumBuffers v Size app.db.ids.IDSChunk v ChunkNumber v FreeSpace v v v v Offset Size MirrorOffset Parent

app.db.ids.IDSConfigValue v ConfigID v ConfigName

136

Application Dependency Discovery Manager: Sensors

v DefaultValue v EffectiveValue v OriginalValue app.db.ids.IDSDatabase v DatabaseLocale v LoggingType v Name app.db.ids.IDSInstance v BitSize v ConnectOption v Home v Host v Name v v v v v ProductName ProductVersion OnConfig Protocol SQLHostFile

v Status v VersionString app.db.ids.IDSSegment v OS_SHM_ADDR v OS_SHM_ID v OS_SHM_KEY v SegmentClass v Size app.db.ids.IDSServerProcess v OSProcessName v PID v VpClass v VpID app.db.ids.IDSSpace v Chunks v ObjectType v PageSize v SpaceName v SpaceNumber app.db.ids.IDSStartupEnvironmentVar v StartupEnvVarName v StartupEnvVarValue

Configuring the access list


To give the IBM Informix sensor access to the Informix Dynamic Server, you must configure the access list.
Chapter 3. Database sensors

137

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


This topic describes common problems that occur with the IBM Informix sensor and presents solutions for those problems.

Sensor cannot retrieve server information


Problem The sensor cannot retrieve information as the Informix Dynamic Server is not started. Solution Enter the oninit command to start the database server.

Message states that nothing exists to be discovered


Problem The sensor runs and completes successfully with the following message:
There was nothing to be discovered.

Solution No active Informix instance is running on the target computer system.

TADDM cannot connect to an Informix database


Problem The following error is displayed in the logs:
encountered error :: com.informix.asf.IfxASFException: Attempt to connect to database server database_name failed

Solution Ensure that the connection from the TADDM server to the Informix port on the database server is open.

Microsoft SQL Server sensor


The Microsoft SQL Server sensor discovers Microsoft SQL Servers.

Sensor name that is used in the GUI and logs


SqlServerSensor

Security issues
The SQL Server access list user must have the following minimal user/group role: db_datareader role. The role is required to access the following tables:

138

Application Dependency Discovery Manager: Sensors

v v v v v

sysdatabases syscurconfigs sysprocesses sysobjects syscolumns

Ensure that the Local Administrators group has SQL access (part of the SQL authorization and configuration).

Model objects created


The sensor creates the following model objects: v db.mssql.SqlServer v db.mssql.SqlServerConfig v db.mssql.SqlServerDatabase v db.mssql.SqlServerModule v db.mssql.SqlServerProcess

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring authentication methods


There are two modes of authentication that TADDM can use to discover an SQL Server. Note the following: v Install SSH on the TADDM gateway as required. 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 WMI Provider 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 SQL Server: Windows authentication For Windows authentication, you must meet the following requirements: v The Windows user used for the discovery of SQL server has to exist on the gateway and on the target machine. v Add the Windows user and password to the access list for the SQL Server. v Add the Windows user and password to the access list for the Windows computer system. v The user must have logon privileges to the SQL Server machine. SQL mode authentication For SQL mode authentication, .NET is used to connect to the SQL Server without having to logon to the Windows Server. You must meet the following requirements:
Chapter 3. Database sensors

139

v Add the Windows user and password to the access list for the Windows computer system. v Add the SQL Server user to the access list for the SQL Server. To determine the type of authentication you need to use, verify with your SQL Server administrator which mode the SQL Server is running. Mixed mode supports both types of authentication.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. The TADDM SQL auth list only applies to SQL authorization (and not Windows authorization). 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: a. User name b. Password For SQL discovery using Windows authorization, TADDM requires that the Windows discovery user is the same as the SQL user. When MSSQL windows mode authentication is used, the user on the target system, which has permission to discover the SQL server, must also exist on the gateway. In addition, do one of the following actions to ensure that the discovery user can access the SQL Server: v Ensure that the sql discover user precedes other windows discover users in the access list (Windows Computer System entries). v Use scopes on the authorization list entries.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the Microsoft SQL Server sensor uses. Microsoft SQL Server sensor uses the following sensor settings: com.collation.discover.agent.SqlServerAgent.UseListeningIp This value specifies how the display names for SQL server instance objects are generated. When the property value is false, the display names for the SQL server instance objects take the following form: host_fqdn + ":" + sql_server_instance_port_number When the property value is true, the display names for the SQL server instance objects take the following form: sql_server_listening_fqdn + ":" + sql_server_instance_port_number The default value is false. com.collation.discover.agent.SqlServerAgent.timeout This value specifies the length of time, in milliseconds, that the sensor runs before timing out.

140

Application Dependency Discovery Manager: Sensors

If this property is not set, the sensor uses the default timeout specified in the com.collation.discover.DefaultAgentTimeout property.

Troubleshooting the sensor


Problems with the sensor might include unsuccessful authorization or discovery, and so on. However, you can recover from these problems.

No details available for SQL Server after discovery


Problem SQL Server is discovered but there are no details provided. Solution Check that the SQL Server authorization has access to the system tables, such as sysdatabases, systables, and so on. If an SQL Server authorization is not used, check the Windows authorization.

Microsoft SQL discovery without datareader authority


Problem Is it possible to discover a Microsoft SQL database without having to grant the required db_datareader role to the entire database. Solution To discover a Microsoft SQL database, without having to grant authority to the 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 new 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 creating the user grant access to the following tables which are used by SQL server sensor:
sysdatabases, syscurconfigs, sysprocesses, sysobjects, syscolumns

v Grant the following access to the TADDM discovery user, which in the following example the user is taddmusr:
GRANT GRANT GRANT GRANT GRANT SELECT SELECT SELECT SELECT SELECT on on on on on sysdatabases to taddmusr; syscurconfigs to taddmusr; sysprocesses to taddmusr; sysobjects to taddmusr; syscolumns to taddmusr;

ProductName attribute is not clear


Problem The ProductName attribute does not present enough information about the product. Solution If you recently migrated from the previous TADDM version, you must rediscover the Microsoft SQL Servers. The attribute includes the SQL Server 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)

Chapter 3. Database sensors

141

Oracle sensor
The Oracle sensor discovers Oracle Database servers.

Sensor name that is used in the GUI and logs


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 to the Oracle user, run the following command: grant execute on dbms_system to oracle_user; The Oracle database account requires CONNECT privileges. The Oracle access list user must have the following role: SELECT_CATALOG_ROLE. The role is required to read/query the following tables: v$version, global_name, v$parameter, dba_data_files, v$log, v$logfile, sys.dba_tables, v$bgprocess, v$process, v$controlfile, v$sga, v$sys_optimizer_env, dba_db_links, dba_tables, dba_views, dba_indexes, dba_sequences, dba_constraints, dba_source, dba_clusters, dba_db_links, dba_tablespaces, dba_synonyms, dba_mviews, dba_rollback_segs, dba_profiles, dba_roles, dba_users, dba_dimensions, dba_sys_privs, dba_role_privs, dba_tab_privs, and dba_ts_quotas.

Asynchronous and script-based discovery support


The Oracle sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. See the TADDM Administrator's Guide for information about configuring for script-based discovery.

Access list configuration requirements


For asynchronous discovery, the access list is not used. For script-based discovery, the Oracle operating system user credential is required (access over SSH) instead of the Oracle user credential, which is required in a nonscript-based discovery. Complete the following steps: 1. Select Database as the component type. 2. Select Oracle as the vendor.

142

Application Dependency Discovery Manager: Sensors

3. Specify the following required information: v The operating system user name for the Oracle user v The operating system password for the Oracle user

Limitations
Some function that is provided by the Oracle sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. The following functions are not supported: v Application descriptor discovery v Oracle RAC discovery v Oracle ASM discovery v Raw schema discovery (the list of tables in the database is limited) v OracleDBLink model object discovery v OracleListener model object discovery

Model objects with associated attributes


The Oracle sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about configuration items in the Oracle environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. OracleASM AsmInstances DiskGroups Name Node Rac OracleASMDisk AsmDiskGroup State Name OracleASMDiskGroup Asm AsmDisks Name State OracleASMInstance BackgroundProcesses Database Host Hostname OracleInstanceStatus
Chapter 3. Database sensors

143

Parameters Parent Port RacDatabase SGAValues SID ServerProcesses OracleBackgroundProcess Description Name Pid OracleControlFile Name OracleDBLink IpAddress Port ServiceName OracleDataFile Name Size TableSpace OracleDatabase ControlFiles DBName DBVersion DataFiles InitValues Name RedoLogFiles SchemaRawData Schemas TableSpaces OracleInitValue Description Name Value OracleInstance BackgroundProcesses ConfigContents Database

144

Application Dependency Discovery Manager: Sensors

Host KeyName Modules Name Port PrimarySAP ProcessPools ProductName ProductVersion SGAValues SID ServerProcesses Status OracleListener BindAddresses Name OracleModule FileName Name Schema OracleRAC Asm HomePath Name OCRLocation PrimaryNode RacDatabases VoteDiskPath OracleRedoLogFile Name Size OracleSGAValue Name Value OracleSchema Name Owner OracleServer ConfigFile Listeners
Chapter 3. Database sensors

145

OracleServerProcess Connections Name PID Ports OracleTableSpace Name Size ProcessPool Name RuntimeProcesses

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 name b. Password To discover Oracle Automatic Storage Management (ASM) file systems, type the user name sys and password.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. com.collation.discovery.oracle.extended This property specifies whether additional configuration values about Oracle database links are stored. The default value is N (No). If you set the property to Y (Yes), the sensor stores additional configuration values about Oracle database links. com.collation.platform.os.ignoreLoopbackProcesses=true The default value is true, which means that the processes that are listening on loopback interfaces are ignored. Therefore, if a server is listening only on the loopback IP address (127.0.0.1), and not on any other externally available 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 listening ports are considered for discovery. You must set this property to true if you want to discover an Oracle Application Server or the WebLogic sensors. For example, if the

146

Application Dependency Discovery Manager: Sensors

WeblogicServerVersionSensor sensor tries to start using a local host address, this property must be set to true.

Troubleshooting the sensor


This topic describes common problems that occur with the Oracle sensor and presents solutions for those problems.

Oracle sensor does not start


Problem The Oracle signature is not matching because either you have renamed the Oracle binaries or you are running a version of the Oracle server that TADDM does not support (Express Edition, for instance). Solution Do not change the names of the binaries and ensure you are using a supported version of Oracle. Also make sure that the TNSListener service is started for the Oracle database.

Sensor fails with Unable to find the servers error


Problem The Oracle database account is not functioning because of one of the following reasons: v The password is not correct. v The account is locked. v The account does not have connect privileges. Solution Update the access list, unlock the account, or add the connect privilege. From the command prompt, test the account by running the sqlplus command, 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 2007 Copyright (c) 1982, 2005, Oracle. All rights reserved. Enter user-name: system Enter password: ERROR: ORA-28000: the account is locked

Sybase sensor
The Sybase sensor discovers Sybase Adaptive Server Enterprise (ASE) database servers.

Sensor name that is used in the GUI and logs


SybaseSensor

Security issues
To assign the minimum privileges to the Sybase discovery user, run the following command:
grant select on sysengines from public

The following tables are queried:


Chapter 3. Database sensors

147

v v v v v v v v v v v v v v v v v

version master..sysconfigures master..sysusages master..syssegments master..sysprocesses master..sysengines master..sysdatabases master..sysdevices master..syscurconfigs master..sysservers master..syssrvroles master..syslogins master..sysloginroles master..syspartitions master..systhresholds master..sysresourcelimits master..systimeranges

Limitations
The Sybase sensor does not collect information about schemas owned by the dbo user.

Model objects with associated attributes


The Sybase sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about storage resources in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. AppConfig v Content v Parent ConfigFile v FixedPath v RealFile v URI LogicalContent FixedPath ProcessPool v CmdLine v Env v Name v Parent v RuntimeProcesses SybaseConfigValue

148

Application Dependency Discovery Manager: Sensors

v v v v v

ConfigUnit Name Parent RunValue Type

v Value SybaseDatabase v Name v Options v v v v v v Owner Parent (SybaseServer) SchemasRawData Segments Tables Thresholds

v Users SybaseDevice v Description v FirstVirtualPageNumber v FixedPath v IsDefaultDisk v v v v v v v v v v v v v v IsDeviceMirrored IsDsyncEnabled IsDumpDevice IsMasterDeviceMirrored IsMirrorEnabled IsPhysicalDisk IsReadsMirrored IsSecondaryMirrorSideOnly IsSerialWrites IsSkipHeader LastVirtualPageNumber MirrorPath Parent (SybaseServer) RealFile

v URI SybaseEngineProcess v CmdLine v Name v PID v Parent v Ports SybaseLogin v AccumulatedDate


Chapter 3. Database sensors

149

v v v v v v v v v v v

FailedLoginCount FullName IsAccountLocked IsPasswordExpired Language Name Parent(SybaseServer) PasswordDate SybaseRoles TotalCPUUsed TotalIOUsed

SybaseModule v Database v FileName v Name v Parent SybaseRemoteServer v IsMessageConfidential v IsMessageIntegrity v IsMutualAuthentication v IsNetworkPasswordEncrypted v v v v v v v v IsReadOnly IsRPCSecurityModelB IsTimeoutEnabled Name NetworkName RemoteNetworkCost RemoteServerClass SybaseServer

SybaseResourceLimitation v AppName v IsEnforcedDuringExecution v IsEnforcedPriorToExecution v v v v v v v v LimitationExceededAction LimitationScope LimitType LimitValue Login Name Parent (SybaseServer) TimeRange

SybaseRole v FailedLoginCount v Name

150

Application Dependency Discovery Manager: Sensors

v Parent v PasswordDate v Status SybaseSegment v Name v Parent v Size SybaseServer v BindAddresses v ConfigContents v ConfigFile v ConfigValues v Databases v v v v v Devices EngineProcesses FullVersion Home Host

v KeyName v Logins v Modules v v v v v v v v v v v Name PrimarySAP ProcessPools ProductName ProductVersion RemoteServers ResourceLimitations ServerProcesses Status SybaseRoles TimeRanges

SybaseServerProcess v Name v PID v Parent SybaseTable v CreationDate v Name v Parent(SybaseDatabase) v Partitions SybaseTablePartition v FirstPage v NumPages
Chapter 3. Database sensors

151

v Parent (SybaseTable) v PartitionID SybaseThreshold v IsLastChance v Name v Parent (SybaseDatabase) v Segment v ThresholdExeededProcedure v ThresholdSize v User SybaseTimeRange v EndDay v EndTime v v v v Name Parent (SybaseServer) StartDay StartTime

SybaseUser v Login v Name v Parent (SybaseDatabase)

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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.

Sybase IQ sensor
The Sybase IQ sensor discovers Sybase IQ database servers.

Sensor name that is used in the GUI and logs


SybaseIQSensor

Security issues
To assign the minimum privileges to the Sybase discovery user, run the following command:
grant execute on sp_iqdbsize

152

Application Dependency Discovery Manager: Sensors

Model objects created


The sensor creates the following model objects: v app.AppConfig v app.ConfigFile v app.db.sybase.SybaseConfigValue v v v v v v v app.db.sybase.SybaseDatabase app.db.sybase.SybaseDevice app.db.sybase.SybaseEngineProcess app.db.sybase.SybaseModule app.db.sybase.SybaseServer app.ProcessPool core.LogicalContent

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 3. Database sensors

153

154

Application Dependency Discovery Manager: Sensors

Chapter 4. Generic sensors


Generic sensors are used by other sensors to discover configuration items.

Anchor sensor
The Anchor sensor is used for discovery behind a firewall.

Sensor name that is used in the GUI and logs


AnchorSensor

Prerequisites
All software components that are needed for discovery from the remote anchor are automatically deployed to the anchor during the discovery process. To exchange data, you must use the Secure Shell (SSH) version 2 protocol.

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. The TADDM server uses SSH to communicate with the remote anchor server. 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 authentication to the remote anchor server. Typically, an account with non-root privilege can be used. However, some commands that TADDM uses during the discovery process can require privilege escalation (typically done using the sudo command). For more information, see the topic Commands that might require elevated privilege in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the Anchor sensor uses. The sensor uses the following entries in the collation.properties file: com.collation.discover.agent.AnchorSensor.timeout=3600000 Specifies the time allowed to start a new anchor server. com.collation.discover.anchor.forceDeployment=true Specifies if all anchors for the discovered scope are to be deployed during discovery startup. Valid values are true and false. The default is true. If you

Copyright IBM Corp. 2008, 2012

155

change the default to false, anchors are deployed only if any IP address from the scope cannot be pinged, or if port 22 cannot be reached on any of the discovered IP addresses. com.collation.discover.anchor.lazyDeployment=false Specifies if files must be copied during anchor deployment, or when the sensor requiring the files is going to be launched. In both cases only different files are copied. Valid values are true and false. The default is false. The following example provides some insight to how this property affects TADDM functionality: The WebSphere Application Server sensor has dependencies in the dist/lib/websphere directory which are 130 MB in size. If the flag is set to false, this data is copied to the target host when the anchor is deployed. If the flag is set to true, the data is copied when the WebSphere Application Server sensor is about to be run on the anchor. If no WebSphere Application Server sensor is run through the anchor, 130 MB is not sent to the remote host. com.collation.discover.anchor.connectType=ssh Specifies whether to connect to the anchor using a ssh tunnel or a direct socket. Valid values are ssh and direct. The default is ssh. To specify the connection type for a particular address, use com.collation.discover.anchor.connectType.1.2.3.4=ssh, where 1.2.3.4 is the address for which you want to specify the connection type. com.collation.platform.session.GatewayForceSsh Specifies whether to force the gateway to act independently of the anchor. Valid values are true and false. Set the value to true to resolve Cygwin issues when both the gateway and anchor are on the same system. When the value is set to true, an SSH session is used to transfer traffic between the gateway and anchor rather than a local session.

Asynchronous discovery sensor


The asynchronous discovery sensor is required for asynchronous discovery. IP addresses that are unreachable (cannot be pinged) are candidates for asynchronous discovery. The asynchronous discovery sensor attempts to determine which of the unreachable IP addresses are valid. The TADDM Administrator's Guide contains information about asynchronous discovery, including how to configure for asynchronous discovery. In asynchronous discovery, the output of the discovery script is an archive file that contains 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 the TADDM server for that IP address. Based on the content of the archive file, the appropriate sensors are scheduled to process their discovery script output. Sensors then perform discovery by parsing the script output instead of directly accessing the target system, as is done in a nonscript-based discovery.

Sensor name that is used in the GUI and logs


ASDSensor

156

Application Dependency Discovery Manager: Sensors

Configuring the sensor


The asynchronous discovery sensor does not use the access list. The asynchronous discovery sensor uses the following entries in the collation.properties file: v com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory v com.ibm.cdb.discover.asd.ProcessUnreachableIPs v com.ibm.cdb.tarpath

Asynchronous discovery ping sensor


The asynchronous discovery ping sensor retrieves the first valid IP address from a discovery archive file. This IP address is used to seed the asynchronous discovery sensor. If you cannot define a discovery scope and you want to run an asynchronous discovery, you can use this sensor.

Sensor name that is used in the GUI and logs


ASDPingSensor

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 sensors in a discovery profile.

Custom application server sensor


The custom application server sensor creates a custom application server that is based on template and runtime process information that is discovered by the generic server sensor. The sensor also collects configuration files or application descriptors if these are specified in the template and performs extension processing to collect additional information.

Sensor name that is used in the GUI and logs


CustomAppServerSensor

Prerequisites
To discover configuration files, the sensor requires that the cksum program and associated libraries are installed on the target operating system.

Limitations
See the limitations for the generic server sensor.

Model objects created


The following model objects are used to create generic AppServers: v app.AppServer v app.db.DatabaseServer v app.j2ee.J2EESever
Chapter 4. Generic sensors

157

v app.web.WebServer The following model objects are used to extend TADDM application sensors: v v v v v v v v app.db.db2.Db2Server app.db.mssql.SqlServer app.j2ee.jboss.JBossServer app.j2ee.weblogic.WebLogicServer app.j2ee.websphere.WebSphereServer app.messaging.exchange.ExchangeServer app.messaging.mq.MQQueueManager app.sms.SMSiteServer

v app.veritas.cluster.VCSCluster v app.web.apache.ApacheServer v app.web.iis.IIsWebServer v app.web.iplanet.IPlanetServer

Custom MIB2 computer system sensor


The custom MIB2 computer system sensor creates a custom computer system that is 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 collect additional information.

Sensor name that is used in the GUI and logs


CustomMib2ComputerSystemSensor

Limitations
See the limitations for the SNMP MIB2 sensor.

Model objects created


The sensor creates the following model objects: v sys.ComputerSystem hierarchy

Generic computer system sensor


The generic computer system sensor discovers the type of a computer system. The results of this sensor are used to start a specific computer system sensor, such as the Linux computer system sensor.

Sensor name that is used in the GUI and logs


GenericComputerSystemSensor

158

Application Dependency Discovery Manager: Sensors

Generic server sensor


The generic server sensor discovers the application servers that are running on a host computer system. The sensor first discovers listening ports (IP address and ports), established connections, and processes that are running on targeted computer systems. Templates are used to match runtime process information. When specified criteria are matched, the information is used to seed specific application sensors, such as the Apache sensor or a custom application server sensor. The processes can be running on IPv4 or IPv6 addresses. For processes that are running on IPv6 only, the processes are discovered, but a seed that starts a more specific sensor is not created. Custom server templates are used to discover application servers that TADDM does not automatically categorize. You can create custom server templates using the Discovery Management Console. If multiple custom server templates match the application runtime process information, only the first custom server template that is matched causes the custom application server sensor to run.

Sensor name that is used in the GUI and logs


GenericServerSensor

Limitations
A sensor that requires credentials and a generic custom sensor can both discover the same target system during multiple discoveries. Depending on the nature of the data discovered without credentials, the system cannot guarantee that objects that are created by the custom server template are reconciled with sensor-created artifacts.

Model objects created


The sensor creates the following model object: v sys.RuntimeProcess

Asynchronous and script-based discovery support


The generic server sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. See the TADDM Administrator's Guide for information about configuring for script-based discovery.

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 for nonscript-based discovery.

Chapter 4. Generic sensors

159

Limitations
Some function that is provided by the generic server sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. On Solaris operating systems that support virtualization, from the global zone, the generic server sensor does not support the discovery of runtime processes in local zones.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. com.collation.platform.os.ignoreLoopbackProcesses=true The default value is true, which means that the processes that are listening on loopback interfaces are ignored. Therefore, if a server is listening only on the loopback IP address (127.0.0.1), and not on any other externally available 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 listening ports are considered for discovery. You must set this property to true if you want to discover an Oracle Application Server or the WebLogic sensors. For example, if the WeblogicServerVersionSensor sensor tries to start using a local host address, this property must be set to true. com.collation.discover.agent.command.netstat.Windows You can use this property to specify a custom command to use instead of the netstat -nao command on a Windows target. You must ensure that any alternative command you specify returns information 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.

IBM Tivoli Utilization sensor


The IBM Tivoli Utilization sensor gathers basic metrics from a target system. The sensor uses the TADDM discovery infrastructure to deploy scripts that run system-level performance monitoring commands on the target system. At specified intervals, the sensor gathers data from the target system and provides it to the TADDM server, where operating system metric objects are created. The IBM Tivoli Utilization sensor provides metrics and a utilization report. You can use this information with the System Connection Topology Report to identify servers that are not used to capacity and do not provide services to other servers.

Sensor name that is used in the GUI and logs


OperatingSystemUtilizationSensor

160

Application Dependency Discovery Manager: Sensors

Prerequisites
For the sensor to discover a target system, the target system must have the following commands installed in the default location for the respective operating system: v v v v compress command netstat command sadc command sar command

On target systems that are running the following operating systems, the following respective 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.

Limitations
The sensor is intended for short-term use (for example, a maximum of one month of use) to analyze servers and identify consolidation targets. The sensor can be used only for the firewall zone in which the TADDM server resides. The use of an anchor server is not supported. Over a longer period of time, for determining server availability, performance, and utilization, or for discovering applications that span firewall zones, use the IBM Tivoli Monitoring product.

Asynchronous and script-based discovery support


The IBM Tivoli Utilization sensor supports asynchronous and script-based discovery. All function that is provided by the sensor during a nonscript-based discovery is supported in an asynchronous or script-based discovery.
Chapter 4. Generic sensors

161

Sensor configuration requirements


For asynchronous discovery, first complete the steps that are described in the TADDM Administrator's Guide in the section about configuring for asynchronous discovery. Before running an asynchronous discovery, you must start the Utilization sensor on the target system to collect utilization data. The discovery script package that is generated 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_7.2.0 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 to collect data, you must wait until after the time interval has elapsed. 4. Periodically collect data by running the taddmasd/scriptsRunner.sh script. This script 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_7.2.0 directory, and run the following command:
./utilizationDeployer.sh -u

See the TADDM Administrator's Guide for information about configuring for script-based discovery.

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 for nonscript-based discovery.

Model objects with associated attributes


The IBM Tivoli Utilization sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about the utilization of your Computer Systems in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. metric.OperatingSystemMetric v Label v v v v MetricName MetricUnitOfMeasure MetricValue StatisticName

162

Application Dependency Discovery Manager: Sensors

net.IpInterface v IpAddress relation.Gauges v Source (OperatingSystemMetric) v Target (OperatingSystem) The following computer system types are discovered: sys.aix.AixUnitaryComputerSystem sys.hpux.HpUxUnitaryComputerSystem sys.linux.LinuxUnitaryComputerSystem sys.sun.SunSPARCUnitaryComputerSystem sys.windows.WindowsComputerSystem The following attribute is associated with these model objects: v signature The following operating system types are discovered: sys.aix.Aix sys.hpux.HpUx sys.linux.Linux sys.sun.Solaris sys.windows.WindowsOperatingSystem The following attribute is associated with these model objects: v OSName

Configuring the sensor


Before running the IBM Tivoli Utilization sensor to gather data from a target machine, you must configure the sensor.

Setting configuration parameters


You can configure the behavior of the IBM Tivoli Utilization sensor by setting the configuration parameters. The following table lists the configuration parameters of the IBM Tivoli Utilization sensor.

Chapter 4. Generic sensors

163

Table 8. Configuration parameters Parameter name operatingMode Description The mode of operation for the sensor. The following values are valid: ONCE Specifies that the collection scripts run once for the interval and numDays, or maxFileSize, specified, whichever comes first. When the collection scripts have finished, the data is collected by the sensor the next time that it runs. The data collected is parsed and stored on the TADDM database. All output files on the target machine are cleaned up.

RESTART Specifies that when the collection scripts finish as normal, the collection scripts are started again. CLEANUP Specifies that any collection currently running on the system is immediately stopped and cleaned up. Once a cleanup operation is called, collection can only be restarted on this machine by setting the operatingMode value to RESTART. collectionMode The mode of collection for the sensor. The following values are valid: ALWAYS Specifies that data is collected each time the sensor is run on the target system, regardless of whether the collection scripts have completed or not. END Specifies that data is collected when the sensor is run on the target system, only if the collection scripts have completed. Except in situations where operatingMode is set to CLEANUP, any discovery performed before the collection scripts have completed results in no data collection.

interval numDays maxFileSize

The collection interval, in minutes, for collection scripts running on the target. Valid values are between 3 minutes and 60 minutes. The number of days that the collection scripts run on the target. Valid values are between 1 day and 35 days. The maximum size, in MB, for the output files created by the collection scripts. Valid values are between 1 MB and 100 MB.

Configuring cleanup options


The IBM Tivoli Utilization sensor has a function that automatically cleans up and removes the collection scripts and data stored on the target machine. It is also possible 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 the collection scripts again carry out a RESTART operation.

164

Application Dependency Discovery Manager: Sensors

Performing manual cleanup


To perform a manual cleanup on a UNIX target machine, complete the following steps: 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 the following 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 report


You can use Utilization BIRT report to generate reports based on the data collected by the IBM Tivoli Utilization sensor.

Procedure
To configure the Utilization BIRT report complete the following steps in the Data Management 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 want to view data, or select ALL to display data for all metrics. Operator Operators are used to restrict the data displayed in the report. From the list of available operators, select an operator, or select N/A to display all 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 value If you specified an operator, and it requires two values, you must specify a corresponding value for the second value. Otherwise, select N/A to display all data for the selected metric. Number of application dependencies The number of application dependencies is used to restrict the data displayed in the report. Specify the number of application dependencies, 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.

Chapter 4. Generic sensors

165

What to do next
To configure the Hourly Peak Server Utilization BIRT report complete the following 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 profile


The IBM Tivoli Utilization sensor is configured through the use of discovery profiles. A default discovery profile, named Utilization Discovery, is provided out of the box. It can be used to perform discoveries as is, or a new profile with customized configuration parameter values can be created. The out-of-the-box Utilization Discovery profile has the following default property values: v operatingMode: ONCE v collectionMode: ALWAYS v interval: 15 v numDays: 35 v maxFileSize: 100 It contains the following default sensors: v Ping sensor v Port sensor v Session sensor v Anchor sensor v Operating system utilization sensor If the default discovery profile is not sufficient for your needs, you can create a profile with customized configuration parameters. To create a customized 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 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. The Create Configuration window is displayed.

166

Application Dependency Discovery Manager: Sensors

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 sensor


This topic describes common problems that occur with the IBM Tivoli Utilization sensor and presents solutions for those problems.

Discovery using cleanup fails when using non-root credentials


Problem A Utilization sensor discovery using the CLEANUP option fails for an endpoint when using non-root credentials. Solution If the endpoint was last discovered by a TADDM server using root credentials, the Utilization sensor scripts deployed to /var/temp have root system access. These scripts cannot be removed by the non-root user ID. To ensure that the cleanup completes correctly, run the Utilization sensor discovery, using the CLEANUP option, on that endpoint, using root credentials. Any existing Utilization sensor scripts are removed.

Metrics data not discovered from a target machine when running an asynchronous discovery
Problem An asynchronous discovery is run, but the IBM Tivoli Utilization sensor does not discover metrics data on the Solaris operating system. Solution You must start the IBM Tivoli Utilization sensor from the extracted script package on the target system.

IP device sensor
The IP device sensor creates a lightweight computer system that represents an IP device on the network.

Sensor name that is used in the GUI and logs


IpDeviceSensor

Model objects created


The sensor creates the following model objects: v net.IpInterface v sys.ComputerSystem
Chapter 4. Generic sensors

167

IP interface sensor
The IP interface sensor discovers IP interfaces.

Sensor name that is used in the GUI and logs


IpInterfaceSensor

Limitations
For IPv6 and IPv4 Router Details, the IP forwarding attribute is set to false regardless of the setting on the discovered Windows system. Do not enable the IP interface sensor. The function that the IP interface sensor provides is now provided by the appropriate computer system sensor. Enabling the IP interface sensor can cause performance issues.

Model objects created


The sensor creates the following model objects: v net.IpInterface v net.IpV4Router v net.IpV6Router v sys.ComputerSystem

Ping sensor
The ping sensor discovers reachable IP addresses. It gathers information from devices and systems that support TCP/IP.

Sensor name that is used in the GUI and logs


PingSensor

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the ping sensor uses. com.collation.discover.agent.PingSensor.timeout=600000 This value specifies the time interval in milliseconds before a timeout occurs during a discovery. com.collation.pingagent.ports=xx,yy,... This property is not defined in the collation.properties file and must be manually added if needed. Valid values are non-negative numbers that represent ports for the ping sensor to use. By default, the ping sensor uses port 22, and if it cannot make a connection to port 22, it uses port 135. To override the default set of ports that the ping sensor uses, add this property to the collation.properties file, and specify the port numbers as a comma-separated list. For example, to add the SNMP port 161 to the existing ports that the Ping sensor uses, add the property with the following values:
com.collation.pingagent.ports=22,135,161

If you want the ping sensor to use only port 161, add the property with the following value:

168

Application Dependency Discovery Manager: Sensors

com.collation.pingagent.ports=161

Troubleshooting the sensor


This topic describes common problems that occur with the Ping sensor and presents solutions for those problems.

Ping sensor discovery ends with an unable to establish loopback connection message
Problem The sensor fails when the scope of discovery is large, due to a timeout error and the following message displays:
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 connection at 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.ClosedByInterruptException at 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>

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

Port sensor
The port sensor discovers open ports on a host system. You can change certain aspects of the port sensor using the sensor configuration file. You must create a custom discovery profile to change the port sensor configuration. Before changing the configuration file, contact IBM Software Support.

Sensor name that is used in the GUI and logs


PortSensor

Chapter 4. Generic sensors

169

Session sensor
The session sensor creates a session between the TADDM server and the target computer system. Typically, the session is either a Secure Shell (SSH) session or a Windows Management Instrumentation (WMI) session.

Sensor name that is used in the GUI and logs


SessionSensor

Configuring the access list


Access list entries with type Computer System are tried sequentially until a session is established. For Windows targets, access list entries with type Computer System (Windows) are used.

Stack Scan sensor


The Stack Scan sensor provides credential-less discovery (less intrusive discovery) of the installed operating system and open ports on a computer system.

Sensor name that is used in the GUI and logs


StackScanSensor

Prerequisites
The sensor requires the following software: v Nmap tool. See Configuring Nmap on page 171 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 during the TADDM installation. v Sudo tool for non-Windows operating systems. For TADDM on AIX operating systems: For the TADDM user to use the nmap tool through sudo, you must install and configure sudo version 1.6.7p5. This is because TADDM has problems with the most recent sudo version, which is version 1.6.9p15.

Security issues
To configure sudo access for the TADDM user, you need to set a nopasswd option in the /etc/sudoers file for the TADDM user.

Limitations
Firewalls between targeted scopes and the TADDM server or remote anchors can severely degrade Stack Scan reliability and performance. In this situation, use remote anchors behind the firewall to improve performance. The version of the operating system might not be discovered properly depending on what the Stack Scan sensor receives from Nmap. For example, Windows Server 2008 is classified as Windows Vista, AIX 6.x as AIX 5.x, Linux for System z as Other Computer System. The discovery of computer systems running the Tru64 UNIX operating system is not supported by Nmap. Use the following command to check the operating system version returned by Nmap:

170

Application Dependency Discovery Manager: Sensors

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 2 or Level 3 discovery, only if the binding TCP ports are the same. All application servers and services discovered using a Level 1 discovery remain following a Level 2 or Level 3 discovery, but applications and services matching on the binding ports are merged.

Model objects created


The sensor creates the following model objects: v net.IpAddress v net.IpInterface v net.L2Interface v sys.aix.Aix v v v v v v sys.aix.AixUnitaryComputerSystem sys.ComputerSystem sys.hpux.HpUx sys.hpux.HpUxUnitaryComputerSystem sys.i5OS.I5OperatingSystem sys.linux.Linux

v sys.linux.LinuxUnitaryComputerSystem v sys.OperatingSystem v v v v v sys.sun.Solaris sys.sun.SunSPARCUnitaryComputerSystem sys.tru64.Tru64 sys.windows.WindowsComputerSystem sys.windows.WindowsOperatingSystem

v sys.zOS.ZOS v sys.zOS.ZSeriesComputerSystem

Configuring the sensor


Before running a discovery of the installed operating system and open ports, you must configure the Stack Scan sensor.

Configuring Nmap
The Stack Scan sensor uses Nmap to gather data about the targets for credential-less discovery.

Installing Nmap
Before installing Nmap for any operating system, see the TADDM support site at http://www.ibm.com/software/sysmgmt/products/support/ IBMTivoliApplicationDependencyDiscoveryManager.html for recent news about your specific operating system and Nmap versions. Nmap is not installed during the TADDM installation. The Nmap tool is available on TADDM DVD #2, and you must install it manually. Install Nmap on the TADDM server and all anchor servers. For more information, see the readme file in the Nmap directory on the DVD.
Chapter 4. Generic sensors

171

Configuring root authority


For non-Windows platforms, give root authority for all commands to the TADDM user ID that starts the TADDM server. If you are using a TADDM anchor server, give root authority to the discovery service account on the anchor server. As root user, add the following line in the /etc/sudoers configuration file, using the visudo command:
TADDM_userid ALL=(ALL) NOPASSWD:ALL

where v 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 delete the line. When the Stack Scan sensor is running with Nmap, the TADDM server user ID can be given root execution permission only for the Nmap command. Add the following line in the /etc/sudoers configuration file:
TADDM_userid ALL=(ALL) NOPASSWD:nmap_path

where v 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 delete the line.

Configuring the Path environment variable


Nmap must be installed on your TADDM server and on all anchor servers. The Nmap command must be in the $PATH environment variable for the TADDM user ID that starts the TADDM server. If you are using a TADDM anchor server, the Nmap command must be in the $PATH environment variable for the discovery service account. On Windows platforms, take the following steps to set the Path system environment variable to include the directory where Nmap is installed: 1. Click Start > Control Panel > System 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.

172

Application Dependency Discovery Manager: Sensors

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

where v 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 operating systems on that computer system.

Limitation
Because of a limitation on AIX, only four active Nmap commands can be run at the 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 nmapMaxOsScanTreads v 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 profile


If you want to create application servers based on the active TCP/IP ports discovered, 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. You can further configure which application servers are to be created based on the discovered ports using the PortAppScanSensor.properties file located in the osgi\plugins\com.ibm.cdb.discover.sensor.idd.stackscan_7.1.2\etc directory. Specific instructions for modifying the association between ports and application servers appear at the top of the PortAppScanSensor.properties file. Configuration errors in the PortAppScanSensor.properties file are reported in the PortAppScanSensor.errors file, located in the osgi\plugins\ com.ibm.cdb.discover.sensor.idd.stackscan_7.1.2\etc directory.

Configuring the collation.properties file entries


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

Chapter 4. Generic sensors

173

The Stack Scan sensor uses the following entries in the collation.properties file: com.collation.sudoCommand=sudo This value specifies the sudo location. com.collation.discover.agent.StackScanSensor.timeout=7200000 This value specifies the time interval in milliseconds before a timeout occurs during a discovery.

Troubleshooting the sensor


This topic describes common problems that occur with the Stack Scan sensor and presents solutions for those problems.

The Stack Scan sensor completes successfully, but no Computer Systems are stored
Problem Doing a Level 1 discovery, the Stack Scan sensor finishes without errors, but it does not store any computer system information. In the services/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 sudo From the TADDM server command line you can successfully do an su - <run as user> and then sudo "nmap -0 10.1.2.3

Solution For non-windows platforms, give root authority for all commands to the TADDM user ID that starts the TADDM server. In addition, if you are using a TADDM anchor server, give root authority to the discovery service account on the anchor server. See Configuring Nmap on page 171 for details.

The Stack Scan sensor does not discover Computer Systems on a Linux system
Problem On a Linux server, when performing a Level 1 discovery, the Stack Scan sensor completes successfully, however, there are no Computer Systems stored. 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 for the run_as user from the command line. Solution Complete the following steps: 1. Type the OS command visudo to edit the /etc/sudoers file 2. Once the file opens, comment out the line Defaults requiretty. 3. Save and close the file.

174

Application Dependency Discovery Manager: Sensors

The network configuration on Linux for System z systems does not create packets that Nmap can read
Linux for System z supports both OSA and VSWICH network interfaces operating in Layer 3 (Network Layer) or Layer 2 (Link Layer) mode. If operating in Layer 2 mode, TCP packets contain a valid ethernet Link Layer header required by Nmap. However, systems using OSA or VSWITCH operating in Layer 3 mode require adding the QETH_OPTIONS=fake_ll=1 to the hardware configuration file for the interface. The following section describes how to modify the hardware configuration file enabling Nmap to operate with Layer 3 network interfaces. For more information about OSA and VSWITCH and their operating modes, see Chapter 7 qeth device driver for OSA-Express (QDIO) and HiperSockets in the Linux on System z Device Drivers, Features, and Commands at: http:// download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/ lk31dd03.pdf. Problem The network configuration on Linux for System z systems does not create packets that Nmap can read. The Stack Scan sensor uses Nmap to gather data about the targets for credential-less discovery. If Nmap is not working properly, the Stack Scan sensor does not store any computer systems. Although the sensor runs without errors, the Linux for System z system that 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 the local host, the following message is displayed:
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0...

Solution Depending on your operating system, perform the following actions: On SUSE Linux for System z systems The network must run with the following option:
QETH_OPTIONS=fake_ll=1

Add this option to the configuration file for the NIC. Depending on the NIC that is used, the name of the file changes. Contact your system administrator for the name of the configuration file that your system uses. The configuration file must be in the /etc/sysconfig/hardware directory. The file name might be hwcfg-qeth-bus-ccw-0.0.5000. On RedHat Linux for System z systems The network must run with the following option:
OPTIONS=fake_ll=1

Add this option to the configuration file for the NIC. Depending on the NIC that is used, the name of the file changes. Contact your system administrator for the name of the configuration file that your system uses.

Chapter 4. Generic sensors

175

The configuration file must be in the /etc/sysconfig/networkscripts directory. The file name might be ifcfg-eth0. Verify that the alias in the /etc/modprobe.conf file includes the following information:
alias eth0 qeth

Computer system displays in the incorrect category


Problem The computer system displays under the OtherComputerSystem category. Solution Check the OS type. If it is correct, check the confidence. If the confidence is below the confidence threshold value (the default is 40), then what you are seeing is expected. You can change the confidence threshold to have the computer system appear under the correct category. The threshold is configured 0 - 100. The threshold can be set using the sensor configuration attribute: confidenceThreshold.

Need enhanced Stack Scan sensor debugging


Problem Need to enable enhanced debugging of the Stack Scan sensor. Solution Complete 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, the results, the configurations used, and more.

Stack Scan sensor fails with a message: sudo: sorry, you must have a tty to run sudo
Problem During a discovery, if the Discovery Management Console where the TADDM server was started is closed, the sensor fails. The message: sudo:sorry, you must have a tty to run sudo is displayed. If you start the 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


Problem The Stack Scan sensor fails with the following error message: "Sorry, sudo has been configured to not allow root to run it." However, you can successfully run sudo nmap at a command line.

176

Application Dependency Discovery Manager: Sensors

Solution This problem occurs when the system is configured not to allow the root user to run the sudo command. To fix the problem, edit the collation.properties file and set the com.ibm.cdb.discover.sensor.idd.stackscan.alwaysUseLocalAnchor property to true. Then restart the TADDM server.

The Stack Scan sensor does not discover Computer Systems on an AIX system
Problem On an AIX server, when performing a Level 1 discovery, the Stack Scan sensor completes successfully, however, there are no Computer Systems stored. 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. Solution Create a discovery profile or edit an existing profile for the Stack Scan sensor. 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.

Chapter 4. Generic sensors

177

178

Application Dependency Discovery Manager: Sensors

Chapter 5. Network sensors


Network sensors discover network devices.

Overview of SNMP sensors


TADDM provides SNMP sensors for discovering SNMP network devices.

Calling sequence for SNMP sensors


The calling sequence for SNMP sensors is dependent on which sensors are enabled in the discovery profile and on what data is discovered. In Level 1 discovery profiles, use the SNMP Light sensor with the Stack Scan sensor to improve the accuracy of the discovery. In Level 2 or Level 3 discovery profiles, use the SNMP MIB2 sensor, which discovers additional data for building detailed Level 2 topologies. Figure 1 on page 180 illustrates the calling sequence for the SNMP Light sensor and 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 discover WMI or SSH ports or if the session sensor cannot establish a connection to the remote host, the port sensor calls the SNMP MIB2 sensor. Figure 2 on page 180 illustrates the calling sequence for SNMP sensors, starting after the SNMP Light sensor or the SNMP MIB2 sensor is called. Depending on the data that the SNMP Light sensor or the SNMP MIB2 sensor discovers 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 the discovery profile. v If the discovered device matches a custom MIB computer system template, the Custom MIB2 computer system sensor is called.

Copyright IBM Corp. 2008, 2012

179

PingSensor

PortSensor

SnmpLightSensor

No

WMI or SSH available

Yes

SessionSensor

No

Connection made

SnmpMib2Sensor

Figure 1. Calling sequence for SNMP Light sensor and SNMP MIB2 sensor

SnmpMib2Sensor SnmpLightSensor

Is Custom CS? Yes

Is Cisco device?

Yes

Yes

Is FC switch?

No

CustomMib2ComputerSystemSensor

CiscoPortSensor

CiscoVlanSensor

FCSwitchSensor

EntityMIBSensor

BridgeSnmpSensor

Figure 2. Calling sequence for SNMP sensors, starting after the SNMP Light sensor or the SNMP MIB2 sensor is called

SNMP MIB walking and debugging SNMP sensors


You 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 you run against the devices using snmpwalk. You can download SNMP query tools that support snmpwalk from http://www.net-snmp.org/download.html. If SNMP V3 authentication is used with encryption, you must also download OpenSSL from http://www.slproweb.com/products/win32openssl.html. The following example shows identical queries, with the first using V3 authentication (although the keys have been removed) and the second using community string authentication:

180

Application Dependency Discovery Manager: Sensors

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 and configuration files


You can use the Computer Systems view to maintain a list of templates that can be used to discover network devices. You can partially define a device, link this definition to a template and then use the template to discover more information about the device. An OID is assigned to a device by the manufacturer and is unique to the make and 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 the Web. This value can also be obtained for the device by querying the SNMPv2-MIB tables for values under the sysObjectID 1.3.6.1.2.1.1.2. The SNMP templates and their configuration files are loaded dynamically during each discovery. It is not necessary to restart the TADDM server after modifying the SNMP templates and their configuration files. It is important to use the correct syntax and enter the correct values when editing templates and configuration files. If your devices are not correctly classified after a discovery, review the SnmpMib2Sensor log or the DiscoveryManager log file. For a description of how to configure the system for SNMP scanning, see the topic Adding network devices in the Using topics in the IBM Tivoli Application Dependency Discovery Manager information center. The following results show different OIDs discovered through SNMP scans of four Foundry devices. In scanning a test environment, the OIDs outlined in Table 9 were discovered. You can perform an Internet search to determine the type of devices. Alternatively, you can ask your network team to identify the specific device types.
Table 9. Foundry OID mapping example Foundry device Foundry FESX448-PREM Foundry FastIron SX Foundry BigIron RX Foundry NetIron MLX OID .1.3.6.1.4.1.1991.1.3.34.2.1.1.2 .1.3.6.1.4.1.1991.1.3.36.6.2 .1.3.6.1.4.1.1991.1.3.40.1.2 .1.3.6.1.4.1.1991.1.3.44.2.2 Description Router Unknown (classified as a switch for our testing) Unknown (classified as a switch for our testing) Unknown (classified as a router for our testing)

You can create templates to classify discovered Foundry devices.

Foundry switch example


This example shows how to create the SNMP computer system template for a Foundry switch.

Chapter 5. Network sensors

181

Procedure
1. 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 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:
Sys OID starts-with .1.3.6.1.4.1.1991.1.3.40

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 the following content to the file:
<?xml version="1.0" encoding="UTF-8"?> <results xmlns="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.0 urn: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 devices matching the Foundry Switch template use the com.collation.platform.model.topology.sys.UnitaryComputerSystem model class, have the type attribute set to Bridge and the manufacturer attribute set to Foundry Networks. Note: The name of the action class file (without the .xml extension) must match the name of the SNMP computer system template.

182

Application Dependency Discovery Manager: Sensors

What to do next
The new template can be used immediately (you do not need to restart the TADDM server).

Foundry router example


This example shows how to create the SNMP computer system template for a Foundry router.

Procedure
1. 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. (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.2

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

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 the following content to the file:
<?xml version="1.0" encoding="UTF-8"?> <results xmlns="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.0 urn: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 devices matching the Foundry Router template use the com.collation.platform.model.topology.sys.UnitaryComputerSystem model class, have the type attribute set to Router and the manufacturer attribute set to Foundry Networks.

Chapter 5. Network sensors

183

Note: The name of the action class file (without the .xml extension) must match 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 the TADDM server).

Alteon port sensor


The Alteon port sensor discovers Alteon switch port information, including ports that 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.

Sensor name that is used in the GUI and logs


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.1 v portInfoTable: .1.3.6.1.4.1.1872.2.1.9.1.1.1

Model objects created


The sensor creates the following model objects: v net.L2Interface v sys.ComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

184

Application Dependency Discovery Manager: Sensors

Alteon SNMP sensor


The 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 the LoadBalancingAlgorithm, is also discovered and stored with the real server group. v Virtual ports, real ports, and virtual servers used to create and store virtual services.

Sensor name that is used in the GUI and logs


AlteonSnmpSensor

Object identifiers (OIDs) that are used


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.1 v v v v v .1.3.6.1.4.1.1872.2.1.5.5.1.2 .1.3.6.1.4.1.1872.2.1.5.5.1.4 .1.3.6.1.4.1.1872.2.1.5.2.1.1 .1.3.6.1.4.1.1872.2.1.5.2.1.2 .1.3.6.1.4.1.1872.2.1.5.2.1.3

v .1.3.6.1.4.1.1872.2.1.5.2.1.10 v .1.3.6.1.4.1.1872.2.1.5.10.1.1 v v v v v v .1.3.6.1.4.1.1872.2.1.5.10.1.2 .1.3.6.1.4.1.1872.2.1.5.10.1.3 .1.3.6.1.4.1.1872.2.1.5.10.1.7 .1.3.6.1.4.1.1872.2.1.5.8.1.1 .1.3.6.1.4.1.1872.2.1.5.8.1.2 .1.3.6.1.4.1.1872.2.1.5.8.1.3

v .1.3.6.1.4.1.1872.2.1.5.8.1.4 v .1.3.6.1.4.1.1872.2.1.5.8.1.5 v .1.3.6.1.4.1.1872.2.1.5.8.1.6

Model objects created


The sensor creates the following model objects: v net.vip.RealServerGroup v net.vip.Vip v net.vip.VipFunction v net.vip.Virtualservice v sys.UnitaryComputerSystem v sys.Function net.vip.RealServer

Chapter 5. Network sensors

185

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Alteon VLAN sensor


The Alteon VLAN sensor discovers Alteon virtual LANs. This sensor uses the Alteon VLAN Membership MIB to discover VLAN contents. The SnmpMib2Sensor invokes the AlteonVlanSensor when VLANs are configured for Alteon devices. AlteonVlanSensor then invokes BridgeSnmpSensor2 for each VLAN discovered. The sensor discovers the VLAN membership table, creates L2Interfaces, and attaches them to the VLAN bridge.

Sensor name that is used in the GUI and logs


AlteonVlanSensor

Object identifiers (OIDs) that are used


The sensor uses the following high-level OIDs to retrieve the attributes: v .1.3.6.1.4.1.1872.2.1.4.2.1 v .1.3.6.1.4.1.1872.2.1.2.3.2.1

Model objects created


The sensor creates the following model objects: v v v v net.L2Interface net.Vlan net.VlanInterface sys.UnitaryComputerSystem

186

Application Dependency Discovery Manager: Sensors

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

BIG-IP port sensor


The BIG-IP port sensor discovers F5 BIG-IP port interfaces. The SnmpMib2Sensor invokes the BigIPPortSensor. The BigIPPortSensor gathers ports from the MIB, for example, the interface through which known ports can be addressed. This allows L2 topology views to be built.

Sensor name that is used in the GUI and logs


BigIPPortSensor

Object identifiers (OIDs) that are used


The sensor follows the standards documented in RFC 1212 to retrieve ports from the 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.

Model objects created


The sensor creates the following model objects: v net.L2Interface v sys.UnitaryComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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.
Chapter 5. Network sensors

187

You can do this using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

BIG-IP SNMP sensor


The BIG-IP SNMP sensor discovers F5 BIG-IP load balancers. The SnmpMib2Sensor invokes the BigIPSnmpSensor if the latter one matches one of the following OIDs: v .1.3.6.1.4.1.3375 v .1.3.6.1.4.1.2021.250.255 The BigIPSnmpSensor collects information about virtual IPs and real server groups.

Sensor name that is used in the GUI and logs


BigIPSnmpSensor

Supported versions
The sensor discovers the following versions: v F5 BIG-IP version 4 (all releases) v F5 BIG-IP version 9 (all releases) v F5 BIG-IP version 10 (all releases)

Supported operating systems


The sensor is used to discover the non-operating system-based network devices.

Object identifiers (OIDs) that are used


The sensor follows the standards that are documented in RFC 1212 to get the Real Server 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.1 v Pool table: 1.3.6.1.4.1.3375.1.1.7.2.1 v Virtual Server table: 1.3.6.1.4.1.3375.1.1.3.2.1 F5 BIG-IP version 9:

188

Application Dependency Discovery Manager: Sensors

v v v v v

Pool member table: 1.3.6.1.4.1.3375.2.2.5.3.2 Pool table: 1.3.6.1.4.1.3375.2.2.5.1.2 Virtual Server table: 1.3.6.1.4.1.3375.2.2.10.1.2 Virtual Server Pool table: 1.3.6.1.4.1.3375.2.2.10.6.2 Virtual Server Rule table: 1.3.6.1.4.1.3375.2.2.10.8.2

v Virtual Address table: 1.3.6.1.4.1.3375.2.2.10.10.2 F5 BIG-IP version 10: v Pool member table: 1.3.6.1.4.1.3375.2.2.5.3.2 v Pool table: 1.3.6.1.4.1.3375.2.2.5.1.2 v Virtual Server table: 1.3.6.1.4.1.3375.2.2.10.1.2 v Virtual Server Rule table: 1.3.6.1.4.1.3375.2.2.10.8.2 v Virtual Address table: 1.3.6.1.4.1.3375.2.2.10.10.2

Model objects created


The sensor creates the following model objects: v bigip.BigIPRealServer v v v v v bigip.BigIPRealServerGroup bigip.BigIPVip bigip.BigIPVipFunction bigip.BigIPVirtualService sys.UnitaryComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

BIG-IP VLAN sensor


The BIG-IP VLAN sensor discovers F5 BIG-IP virtual LANs.

Chapter 5. Network sensors

189

The SnmpMib2Sensor invokes the BigIPVlanSensor. A VlanInterface model object is created for each VLAN in the VLAN map (for example, the interface through which known VLANs can be addressed). This allows L2 topology views to be built.

Sensor name that is used in the GUI and logs


BigIPVlanSensor

Object identifiers (OIDs) that are used


The BigIPVlanSensor follows the standards documented in RFC 1212 to get the VLAN Interface. Specifically, OID .1.3.6.1.4.1.3375.1.1.10.2.1 is queried to get the VLAN interface through which the VLAN from the MIB can be discovered. The BigIPVlanSensor runs the agent's discovery step and discovers Vlans and VlanInterfaces and throws an AgentException if the discovery fails.

Model objects created


The sensor creates the following model objects: v bigip.BigIPVlan v net.L2Interface v net.VlanInterface

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Bridge SNMP sensor


The Bridge SNMP sensor expands and updates the port data that is discovered by the SNMP MIB2 sensor (which is the data that is shown in the Ports tab of the Details pane).

190

Application Dependency Discovery Manager: Sensors

The SNMP MIB2 sensor invokes the Bridge SNMP sensor. The Bridge SNMP sensor gathers the MAC address data of attached devices (specifically, the interface number through which known MAC-addressed devices can be reached), which is needed to build the Level 2 topology views. The sensor follows the standards documented in RFC 1286 to retrieve some of the MAC 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, as shown in the following example. These OIDs are then queried to determine the interface 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.1 SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.42.208.0 = Hex-STRING: 00 12 F2 2A D0 00 SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.50.0.0 = Hex-STRING: 00 12 F2 32 00 00 SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.51.88.0 = Hex-STRING: 00 12 F2 33 58 00 SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.218.128.177 = Hex-STRING: 00 12 F2 DA 80 B1 SNMPv2-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 System L2 Interfaces that are attached to the switch. The SNMP MIB2 sensor provides generic information about the existence of the device interfaces, and the Bridge SNMP sensor provides detailed information about the MAC addresses that are accessible through the device interfaces. For example, Table 10 shows the names of MAC devices that have been discovered by the Bridge SNMP sensor. TADDM can determine the names because the computer system that owns that MAC device has been discovered. If the name of the device is unknown, the MAC address is used.
Table 10. Level 2 bridge topology data Name ethernet 1/9 ethernet 1/10 ethernet 1/11 ethernet 1/12 ethernet 10/2 Computer System L2 Interfaces NC84CDRS1LDPC02 00040DFDE53 NC84CDRS1LDPC04 NC84CDRS1LDPC03 000CDBF90C19

The sensor also follows the standards that are documented in RFC 1286 to retrieve some 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

Chapter 5. Network sensors

191

Sensor name that is used in the GUI and logs


BridgeSnmpSensor

Object identifiers (OIDs) that are used


The sensor follows the standards documented in RFC 1286 to get some of the MAC 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. These OIDs are then queried to retrieve the interface through which the MAC device can be accessed.

Model objects created


The sensor creates the following model objects: v net.L2Interface v net.Segment v sys.ComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Bridge SNMP 2 sensor


The Bridge SNMP 2 sensor expands and updates the port data that is discovered by 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 is discovered. The data that is discovered is the same as for the Bridge SNMP sensor, but it is discovered for all VLANs.

192

Application Dependency Discovery Manager: Sensors

Sensor name that is used in the GUI and logs


BridgeSnmpSensor2

Object identifiers (OIDs) that are used


The sensor follows the standards documented in RFC 1286 to get some of the MAC 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. These OIDs are then queried to retrieve the interface through which the MAC device can be accessed.

Model objects created


The sensor creates the following model objects: v net.L2Interface v net.Segment v sys.ComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Check Point sensor


The Check Point sensor discovers Check Point FireWall-1 running on non-Windows platforms, such as Solaris or Check Point IPSO.

Sensor name that is used in the GUI and logs


CheckpointSensor

Chapter 5. Network sensors

193

Prerequisites
You must have the following access: v SSH access that can run lsof v Read permission to the $CPMDIR/conf/objects.C directory on the system where the Check Point FireWall-1 is running v Execute permission for the $CPMDIR/bin/fw command v 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.

Configuring the collation.properties file entries


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

collation.properties file entries


The following properties can require elevated privilege: v com.collation.discover.agent.command.cat.SunOS=cat v com.collation.discover.agent.command.cat.SunOS. 1.2.3.4=sudo cat

Troubleshooting the sensor


This topic describes common problems that occur with the Check Point sensor and presents solutions for those problems.

Unable to retrieve information from the Check Point server host machine
Problem The Check Point sensor fails during discovery. Solution Verify 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 running v Execute permission for the $CPMDIR/bin/fw command v Read permission to the $CPMDIR/conf/*.W files, which contain the editable versions of the rule sets

Check Point SNMP sensor


The Check Point SNMP sensor discovers SNMP information that is associated with Check Point FireWall-1 firewalls.

Sensor name that is used in the GUI and logs


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.

194

Application Dependency Discovery Manager: Sensors

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.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Cisco Adaptive Security Appliance sensor


The Cisco Adaptive Security Appliance (ASA) sensor discovers ASA devices that are used as IP firewall and network address translation appliances. The Cisco ASA sensor gathers data about ASA devices. In addition, the sensor discovers 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 in the Vip table.

Sensor name that is used in the GUI and logs


v ASASensor v CiscoApplianceVersionSensor

Limitations
In TADDM Change History reports, the Cisco ASA device is displayed as a PIX device.

Chapter 5. Network sensors

195

Model objects created


The sensor creates the following model objects: v cisco.CiscoPixComputerSystem v core.LogicalContent v net.L2Interface v v v v v v sys.OperatingSystem vip.RealServer vip.RealServerGroup vip.Vip vip.VipFunction vip.VirtualService

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 entries


This topic lists the collation.properties file entries that the Cisco ASA sensor uses. The sensor uses the following entries in the collation.properties file: com.collation.asa.pager.command=terminal pager 0 Add this property and value if the user specified in the access list does not have access to the configure terminal command. The terminal pager 0 value instructs the pager command to force the ASA device to return responses in one batch. com.collation.CiscoSshTimeout=9000 Increase the CiscoSshTimeout value (in milliseconds) if the target system is available and running, but the following error is displayed:
The ssh login did not work correctly

com.collation.CiscoExpectTimeout=60000 Increase the CiscoExpectTimeout value (in milliseconds) if the target system is available and running, but the following error is displayed:
The ssh login did not work correctly

Cisco Discovery Protocol sensor


The Cisco Discovery Protocol sensor uses the Cisco Discovery Protocol MIB to discover Layer 2 segments on the network.

196

Application Dependency Discovery Manager: Sensors

The CdpSensor discovers cdpCacheDeviceId and cdpCacheDevicePort information and builds the local interface for the peer devices which is used to build the segment.

Sensor name that is used in the GUI and logs


CdpSensor

Object identifiers (OIDs) that are used


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.0 v Cache Device Id : .1.3.6.1.4.1.9.9.23.1.2.1.1.6 v Cache Device Port : .1.3.6.1.4.1.9.9.23.1.2.1.1.7

Model objects created


The sensor creates the following model objects: v net.L2Interface v net.Segment v sys.ComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console. 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 must enable the password.

Troubleshooting the sensor


This topic describes common problems that occur with the Cisco Discovery Protocol sensor and presents solutions for those problems.

Chapter 5. Network sensors

197

After TADDM completes the discovery, the sensor name appears in the GUI, but the Config files tab does not appear as expected
Problem Telnet access is not configured correctly. Solution Configure Telnet access with a user name and password, and make sure that the password is enabled.

Cisco IOS sensor


The Cisco Internetwork Operating System (Cisco IOS) sensor discovers Cisco network 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.

Sensor name that is used in the GUI and logs


CiscoIOSSensor

Model objects created


The sensor creates the following model objects: v agent.CiscoIOSAgentConfiguration v core.LogicalContent v sys.ComputerSystem

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the discovery profile


This topic describes how to configure the discovery profile. The following sensor attributes can be modified from the discovery profile: useSshFirst The default value for this attribute is false. The protocols are probed in the order: Telnet protocol, SSH2, and SSH1. If the value is true: the protocols are probed in the order: SSH2, SSH1, and Telnet protocol. commands The default values for this attribute are show running-config;show startup-config, if no value is entered. The output for each command is saved as a configuration file. To add additional commands, type the default commands show running-config;show startup-config and add additional commands to the list. Separate each command with a semicolon. Alternatively, type the commands you want to run.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. To configure the access list, complete the following steps:

198

Application Dependency Discovery Manager: Sensors

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. Leave the enable password blank if not required. 3. If your Cisco IOS sensor is using a Telnet protocol and does not prompt for a user name, type default in the user name field.

Cisco port sensor


The Cisco port sensor discovers Cisco switch port information. The CiscoPortSensor discovers the interface index and duplex state for the port. It also determines the auto negotiation status.

Sensor name that is used in the GUI and logs


CiscoPortSensor

Object identifiers (OIDs) that are used


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.

Model objects created


The sensor creates the following model objects: v net.L2Interface v sys.UnitaryComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console. 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 must enable the password.
Chapter 5. Network sensors

199

Cisco VLAN sensor


The Cisco VLAN sensor uses the Cisco VLAN Membership MIB to discover VLAN contents. The SnmpMib2Sensor invokes CiscoVlanSensor when VLANs are configured for Cisco devices. The CiscoVlanSensor then invokes BridgeSnmpSensor2 for each VLAN discovered. The sensor discovers the VLAN membership table, creates L2Interfaces, and attaches them to the VLAN bridge.

Sensor name that is used in the GUI and logs


CiscoVlanSensor

Object identifiers (OIDs) that are used


The sensor follows the standards documented in RFC 1286 to get the VLAN interface. 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 table v OID .1.3.6.1.4.1.9.9.46.1.2.1.1 to get the management domain table v OID .1.3.6.1.4.1.9.9.46.1.3.1.1 to get the vtp VLAN table v OID .1.3.6.1.4.1.9.9.46.1.6.1.1 to get the VLAN trunk port information.

Model objects created


The sensor creates the following model objects: v net.L2Interface v net.Vlan v net.VlanInterface v sys.UnitaryComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

200

Application Dependency Discovery Manager: Sensors

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 must enable the password.

CiscoWorks sensor
The CiscoWorks sensor collects data from CiscoWorks servers. The sensor works by invoking the RME servlet.

Sensor name that is used in the GUI and logs


CiscoWorksSensor, CiscoWorks405FileSensor, CiscoWorks405FileUDS, CiscoWorks405UDS, CiscoWorksFileSensor, CiscoWorksFileUDS, and CiscoWorksUDS

Model objects with associated attributes


The CiscoWorks sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about configuration items from CiscoWorks servers. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. net.IpAdress v DotNotation net.IpInterface v IpAddress v L2Interface net.L2Interface v Description v Encapsulation v HwAddress v Name net.Router v Forwarding v Name sys.OperatingSystem v Description v Name v OSName v OSVersion sys.UnitaryComputerSystem v Functions v Manufacturer v Model v Name v OSRunning v SerialNumber
Chapter 5. Network sensors

201

v Type

Configuring the access list


This topic describes the access details that you require, depending on your configuration. To configure the access list, complete the following steps: 1. Use CiscoWorks as the Component Type. 2. Specify the following required information: a. User name b. Password

Entity MIB sensor


The Entity MIB sensor can discover only known devices. It follows the standards that are documented in RFC 2737 to retrieve some of the physical configuration information for the device. The Entity MIB sensor gathers the data that is shown in the PhysicalPackage tab of the Details pane. This data is used to store information about physical parts of the device 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 information according to RFC 2466. OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses. These OIDs are then queried to determine the interface through which the MAC device can be accessed. If the SNMP MIB2 sensor also runs, additional information is gathered and shown in the Router Details, Bridge Details, IP, and Ports tabs.

Sensor name that is used in the GUI and logs


EntityMIBSensor

Object identifiers (OIDs) that are used


The sensor uses the following OIDs: v .1.3.6.1.2.1.47.1.1.1.1.2 v .1.3.6.1.2.1.47.1.1.1.1.3 v .1.3.6.1.2.1.47.1.1.1.1.4 v .1.3.6.1.2.1.47.1.1.1.1.5 v .1.3.6.1.2.1.47.1.1.1.1.6 v .1.3.6.1.2.1.47.1.1.1.1.7 v .1.3.6.1.2.1.47.1.1.1.1.8 v .1.3.6.1.2.1.47.1.1.1.1.9

202

Application Dependency Discovery Manager: Sensors

v v v v

.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 queries OID .1.3.6.1.2.1.55.1.1.0. which contains the IPV6 information per RFC 2466. The sensor also queries OID .3.6.1.2.1.17.4.3.1.1. which returns a list containing OIDs for known MAC addresses. These OIDs are then queried to get the interface through which the MAC device can be accessed.

Model objects created


The sensor creates the following model objects: v phys.physconn.Slot v physconn.PhysicalConnector v physpkg.Chassis v physpkg.Fan v physpkg.PhysicalFrame v v v v v physpkg.PhysicalPackage physpkg.otherPhysicalPackage physpkg.PowerSupply physpkg.Sensor sys.ComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Extreme VLAN sensor


The Extreme VLAN sensor extracts VLAN information from Extreme Networks switches.

Chapter 5. Network sensors

203

The SnmpMib2Sensor invokes the ExtremeVlanSensor when VLANs are configured for the device.

Sensor name that is used in the GUI and logs


ExtremeVlanSensor

Object identifiers (OIDs) that are used


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.

Model objects created


The sensor creates the following model objects: v net.L2Interface v sys.UnitaryComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

IBM BladeCenter SNMP sensor


The IBM BladeCenter SNMP sensor discovers and collects configuration information about IBM BladeCenter chassis. The sensor uses SNMP (Simple Network Management Protocol) to discover and query BladeCenter infrastructure components. The Management Module (MM) and the Advanced Management Module (AMM) are the central points of management for the IBM BladeCenter chassis.

204

Application Dependency Discovery Manager: Sensors

Sensor name that is used in the GUI and logs


BladeCenterSnmpSensor

Limitations
The following limitations apply: v The sensor cannot discover a BladeCenter chassis if the Management Module is not responsive. v The sensor cannot discover BladeCenters that have two configured network interfaces (eth0 and eth1). v You cannot start the first BladeCenter discovery against an empty database. Computer system sensors that discover operating systems running on blades (such as Linux and Windows) must be run first. This limitation applies only to the first BladeCenter discovery. v The sensor might not obtain sufficient Vital Product Data (VPD) against Redundant Management Modules to create certain model objects. Instances of the ComputerSystem and BladeCenterManagementModule classes representing Redundant Management Modules, for example, might not be created. In this case, instances of the Board class represent the module. v After discovering one or more BladeCenters using the BladeCenter sensor, the components BladeCenter and BladeCenter Management Module are not present in the list of component types available for use with custom queries. Therefore you cannot run a custom query for these types of components. This issue applies only to the TADDM Data Management Portal and not to the Discovery Management Console. v The BladeCenter does not have L2 interfaces but has Management Modules which have L2 interfaces. To view the L2 interfaces of the Management Modules contained 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.

Model objects created


The sensor creates the following model objects: v core.LogicalContent v enums.AlertLevelEnum v enums.PhysTypeEnum v enums.SlotStateEnum v IpAddress net v v v v v L2Interface net.BindAddress net.Fqdn net phys.physconn.PhysicalConnector phys.physconn.Slot

v phys.physpkg.Board v phys.physpkg.Chassis v phys.physpkg.Fan


Chapter 5. Network sensors

205

v v v v v v v v v v v

phys.physpkg.PhysicalFrame phys.physpkg.PowerSupply sys.blade.Alert sys.blade.BladeCenterManagementModule sys.blade.LoginProfile sys.ComputerSystem sysControlSoftware sys.DNSService sys.LDAPService sys.ServiceAccessPoint sys.SMTPService

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the discovery profile


This topic describes how to configure the discovery profile. You can configure the BladeCenterSnmpSensor using the Discovery Management 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. scanL2Interfaces Get L2 interfaces for the chassis, when enabled. For more information, see the topic Creating discovery profiles in the Using topics in the IBM Tivoli Application Dependency Discovery Manager information center. When the BladeCenterSnmpSensor is enabled, you must also enable the SnmpLightSensor or SnmpMIB2Sensor for the BladeCenterSnmpSensor to function correctly.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:

206

Application Dependency Discovery Manager: Sensors

Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key

To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Troubleshooting the sensor


This topic describes common problems that occur with the IBM BladeCenter SNMP sensor and presents solutions for those problems.

An SNMP time out error occurs


Problem The sensor generates an SNMP time out error during discovery. Solution Increase the snmpTimeout parameter for the BladeCenterSnmpSensor using the Discovery Management Console.

LAN Manager SNMP sensor


The LAN Manager SNMP sensor discovers LAN Manager and retrieves information contained in LAN Manager SNMP MIBs.

Sensor name that is used in the GUI and logs


LanManagerSnmpSensor

Object identifiers (OIDs) that are used


The sensor uses the following high-level OIDs to retrieve the attributes: v .1.3.6.1.4.1.77.1.1.1.0 v v v v v v .1.3.6.1.4.1.77.1.1.2.0 .1.3.6.1.4.1.77.1.2.3.1.1 .1.3.6.1.4.1.77.1.2.3.1.2 .1.3.6.1.4.1.77.1.2.3.1.3 .1.3.6.1.4.1.77.1.2.3.1.4 .1.3.6.1.4.1.77.1.2.3.1.5

Model objects created


The sensor creates the following model objects: v sys.windows.WindowsComputerSystem v sys.windows.WindowsOperatingSystem v sys.windows.WindowsService

Configuring the access list


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

Chapter 5. Network sensors

207

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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

NetFlow sensor
The NetFlow sensor discovers network traffic information that is collected by the Tivoli Netcool Performance Flow Analyzer server. Tivoli Netcool Performance Flow Analyzer is a flow-based, network profiling system that analyzes and aggregates NetFlow data. It compiles the network flow data into reports and makes the reports available to the NetFlow sensor. Using Cisco NetFlow, network flow information is collected from routers and switches and is passed, in the form of UDP packets, to a Tivoli Netcool Performance Flow Analyzer server. See the TADDM Installation Guide for information about installing the Tivoli Netcool Performance Flow Analyzer server.

Sensor name that is used in the GUI and logs


NetFlowSensor

Limitations
A limited amount of Computer System information is discovered by using the NetFlow sensor. After a discovery, many of the fields in the Details tab of the Computer System remain empty. The discovery scope and port information, defined in the scopeFilter and includePorts properties, override any scope or port settings defined for individual discoveries. If you perform a discovery of more than one subset simultaneously, an instance of the NetFlow sensor starts for each subset. One instance of the NetFlow sensor collects computer system and network connection information from all the subnets defined by the scopeFilter property. All other instances of the NetFlow sensor return a null value.

208

Application Dependency Discovery Manager: Sensors

Model objects created


The sensor creates the following model objects: v sys.ComputerSystem v net.IpInterface v net.IpAddress v net.LogicalConnection v net.NetworkConnection

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the discovery profile


This topic describes how to configure the discovery profile. To collect NetFlow data, the NetFlow sensor requires the Tivoli Netcool Performance Flow Analyzer server to be running. As part of the TADDM server installation process, you can install the Tivoli Netcool Performance Flow Analyzer server. For more information, see the Installing topics in the IBM Tivoli Application Dependency Discovery Manager information center. Complete the following steps to configure the NetFlow sensor: 1. Create a discovery profile that is not based on another profile. 2. Select NetFlowSensor, and click New to create a NetFlowAgentConfiguration. 3. Set the following parameters, or accept the default values: collectorDataDirectory The full path of the reports directory. The default location for this directory is /var/lib/aurora/sites/taddm/reports. collectorIP The full host name or IP address of the Tivoli Netcool Performance Flow Analyzer server. includePorts The list of ports monitored. Information is collected by the NetFlow sensor for only the ports specified. The default value is
80,110,111,135,139,389,443,445,600,605,631,636,732,742,767,900,993, 995,1098,1099,1352,1414,1415,1420,1434,1477,1478,1498,1500,1501,1503, 1521,1522,1525,1529,1645,1646,1881,1883,1950,2001,2049,2102,2433,2809, 3201,3427,4000,4431,4848,4849,4948,8001,8879,9080,9430,9433,9435,9443, 50000,50001,50002,50003,50004,60000,60040

processAppToAppData The default value for this attribute is true. The sensor processes the Tivoli Netcool Performance Flow Analyzer a2a (port to port) files for computer system to computer system connections. Change this attribute to false to prevent this processing. ProcessComputerSystemToAppData The default value for this attribute is true. The sensor processes the Tivoli Netcool Performance Flow Analyzer cfa files for system to system information. Change this attribute to false to prevent this processing.

Chapter 5. Network sensors

209

ProcessIPv4Data The default value for this attribute is true. Change this attribute to false to filter out the IPv4 data. ProcessIPv6Data The default value for this attribute is true. Change this attribute to false to filter out the IPv6 data. restrictiveIPv4Data The default value for this attribute is true. The sensor requires both computer systems to be in the scope of discovery for the relationship to be created for the IPv4 data. Change this attribute to false to require only one end point to be present. restrictiveIPv6Data The default value for this attribute is true. The sensor requires both computer systems to be in the scope of discovery for the relationship to be created for the IPv6 data. Change this attribute to false to require only one end point to be present. scopeFilter The scope of a discovery using the NetFlow sensor. If a scope filter is set, only information about the subnets or subnet specified is collected. The default value is for no scope filter set. In the results of a discovery, the NetFlow sensor reports all network connections. The connections discovered are through Cisco NetFlow either to or from the computer systems in the scope filter for the sensor. Many of these connections are to or from other computer systems that are outside of the scope filter for the sensor and that might or might not have been previously discovered. 4. Click OK. The NetFlow sensor can retrieve NetFlow reports from the remote Tivoli Netcool Performance Flow Analyzer server. Depending on the network traffic, it can take approximately 24 hours for the remote Tivoli Netcool Performance Flow Analyzer server to produce data that can be read by the NetFlow sensor. To enable retrieval, use one of the following methods: v If the number of report files becomes large, the most efficient method is to mount the report files directory of the remote Tivoli Netcool Performance Flow Analyzer server on the TADDM server. For this method, enter the location of the mounted drive as the value of the collectorDataDirectory attribute, and leave the value of the collectorIP attribute empty. v Configure the TADDM access list, and enter the IP address of the remote server as the value of the collectorIP attribute.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. If Tivoli Netcool Performance Flow Analyzer is not installed on the TADDM server, NetFlowSensor uses the ComputerSystem access entry to access the Tivoli Netcool Performance Flow Analyzer server.

210

Application Dependency Discovery Manager: Sensors

NetScreen SNMP sensor


The NetScreen SNMP sensor discovers the NAT configuration from Juniper Networks NetScreen devices and retrieves service values such as ServiceIndex, serviceName, and ServiceTransProto from NetScreen and looks up the virtualservice. The NetScreenSNMPSensor uses the Netscreen SNMP MIBs.

Sensor name that is used in the GUI and logs


NetscreenSnmpSensor

Object identifiers (OIDs) that are used


The sensor uses the following high-level OIDs to retrieve the attributes: v .1.3.6.1.4.1.3224.11.1.1.1 v .1.3.6.1.4.1.3224.11.1.1.2 v .1.3.6.1.4.1.3224.11.1.1.3 v .1.3.6.1.4.1.3224.11.1.1.4 v .1.3.6.1.4.1.3224.11.1.1.5 v v v v v .1.3.6.1.4.1.3224.11.1.1.6 .1.3.6.1.4.1.3224.13.1.1.1 .1.3.6.1.4.1.3224.13.1.1.2 .1.3.6.1.4.1.3224.13.1.1.4 .1.3.6.1.4.1.3224.13.1.1.5

v .1.3.6.1.4.1.3224.13.1.1.6 v .1.3.6.1.4.1.3224.13.1.1.7 v v v v v .1.3.6.1.4.1.3224.13.1.1.8 .1.3.6.1.4.1.3224.11.3.1.1.1 .1.3.6.1.4.1.3224.11.3.1.1.2 .1.3.6.1.4.1.3224.11.3.1.1.3 .1.3.6.1.4.1.3224.11.3.1.1.4

v .1.3.6.1.4.1.3224.11.3.1.1.5 v .1.3.6.1.4.1.3224.11.3.1.1.6 v v v v v .1.3.6.1.4.1.3224.11.3.2.1.1 .1.3.6.1.4.1.3224.11.3.2.1.2 .1.3.6.1.4.1.3224.11.3.2.1.3 .1.3.6.1.4.1.3224.11.3.2.1.5 .1.3.6.1.4.1.3224.11.3.2.1.6

Model objects created


The sensor creates the following model objects: v net.vip.RealServer v net.vip.RealServerGroup v net.vip.Vip v net.vip.VipFunction v net.vip.VirtualService
Chapter 5. Network sensors

211

v sys.ComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Nokia SNMP sensor


The Nokia SNMP sensor discovers information contained in Nokia SNMP MIBs. The NokiaSNMPSensor discovers Access Control List (ACL) configurations (ACL rules) and mapped interfaces for Nokia SNMP devices based on the FQDN, signature, and Object_ID.

Sensor name that is used in the GUI and logs


NokiaSnmpSensor

Object identifiers (OIDs) that are used


The sensor uses the following high-level OIDs to retrieve the attributes: v v v v v v v v v v v v .1.3.6.1.4.1.94.1.16.4.1.1.1.1 .1.3.6.1.4.1.94.1.16.4.1.1.1.2 .1.3.6.1.4.1.94.1.16.4.1.1.1.3 .1.3.6.1.4.1.94.1.16.4.1.1.1.4 .1.3.6.1.4.1.94.1.16.4.1.1.1.5 .1.3.6.1.4.1.94.1.16.4.2.1.1.1 .1.3.6.1.4.1.94.1.16.4.2.1.1.2 .1.3.6.1.4.1.94.1.16.4.2.1.1.3 .1.3.6.1.4.1.94.1.16.4.2.1.1.4 .1.3.6.1.4.1.94.1.16.4.2.1.1.5 .1.3.6.1.4.1.94.1.16.4.2.1.1.6 .1.3.6.1.4.1.94.1.16.4.2.1.1.7

212

Application Dependency Discovery Manager: Sensors

v v v v v v v v v

.1.3.6.1.4.1.94.1.16.4.2.1.1.8 .1.3.6.1.4.1.94.1.16.4.2.1.1.9 .1.3.6.1.4.1.94.1.16.4.2.1.1.10 .1.3.6.1.4.1.94.1.16.4.2.1.1.11 .1.3.6.1.4.1.94.1.16.4.2.1.1.12 .1.3.6.1.4.1.94.1.16.4.2.1.1.13 .1.3.6.1.4.1.94.1.16.4.2.1.1.14 .1.3.6.1.4.1.94.1.16.4.2.1.1.15 .1.3.6.1.4.1.94.1.16.4.2.1.1.16

Model objects created


The sensor creates the following model objects: v net.acl.Acl v net.acl.AclFunction v net.acl.Rule v net.L2Interface v sys.ComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

PIX sensor
The PIX sensor discovers Cisco PIX devices that are used as IP firewall and network address translation appliances. The PIX sensor gathers data about the CiscoPIX operating system running on PIX devices. 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.

Chapter 5. Network sensors

213

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 logs


v CiscoApplianceVersionSensor v PixSensor

Prerequisite
For configurations that have multiple context configurations, specify in the discovery 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 displayed in the contextual topology view.

Model objects created


The sensor creates the following model objects: v cisco.CiscoPixComputerSystem v core.LogicalContent v net.L2Interface v sys.OperatingSystem v vip.RealServer v v v v vip.RealServerGroup vip.Vip vip.VipFunction vip.VirtualService

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 entries


This topic lists the collation.properties file entries that the PIX sensor uses. com.collation.pix.pager.command This value specifies to use the pager command to force the PIX to return the entire response at once, rather than one screen at a time. Add this entry, if it is not possible to run the configure terminal command.

214

Application Dependency Discovery Manager: Sensors

SNMP Light sensor


The SNMP Light sensor supports Level 1 discovery of SNMP network devices. In Level 1 discovery profiles, use the SNMP Light sensor with the Stack Scan sensor to improve the accuracy of the discovery. In Level 2 or Level 3 discovery profiles, use the SNMP MIB2 sensor, which discovers additional data for building detailed Level 2 topologies. The SNMP Light sensor gathers the data that is shown in the following tabs of the Details pane: v General v SNMP Info The SNMP Light sensor and the SNMP MIB2 sensor gather generic information from 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.0 SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software IOS (tm) s72033_rp Software (s72033_rp-JK9SV-M), Version 12.2(17d)SXB11, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (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 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.4.0 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

Sensor name that is used in the GUI and logs


SnmpLightSensor

Model objects created


The sensor creates the following model objects: v sys.UnitaryComputerSystem v sys.OperatingSystem v sys.SnmpSystemGroup

Configuring the access list


This topic describes the access details that you require, depending on your configuration. To configure the access list, enter the following information:

Chapter 5. Network sensors

215

v For SNMP V1 and V2 discovery, enter the correct Community String into the access list. You can do this using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

SNMP MIB2 sensor


The SNMP MIB2 sensor supports Level 2 discovery of SNMP network devices. In Level 1 discovery profiles, use the SNMP Light sensor with the Stack Scan sensor to improve the accuracy of the discovery. In Level 2 or Level 3 discovery profiles, use the SNMP MIB2 sensor, which discovers additional data for building detailed Level 2 topologies. The SNMP MIB2 sensor discovers basic SNMP information about the device and other information such as router details, bridge details, IP data (both IPv4 and IPv6), and port data. The SNMP MIB2 sensor calls the Entity MIB sensor and the Bridge SNMP sensor if they are enabled in the discovery profile. Other sensors are called as the SNMP MIB2 sensor detects the devices that TADDM supports (for example, the Cisco port sensor and the Cisco VLAN sensor are called if a Cisco device is detected). The SNMP MIB2 sensor gathers the data that is shown in the following tabs of the Details pane: v General v SNMP Info v IPv6 Router Details v IPv4 Router Details v IP v Interfaces The SNMP Light sensor and the SNMP MIB2 sensor gather generic information from 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.0 SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software IOS (tm) s72033_rp Software (s72033_rp-JK9SV-M), Version 12.2(17d)SXB11, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco Systems, Inc. Compiled T

216

Application Dependency Discovery Manager: Sensors

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 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.4.0 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-MIB and IP-FORWARD-MIB modules (updated in RFC 4293 and RFC 4292), the sensor collects IP interface, forwarding, and routing information. The following OIDs are queried:
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)

ipAddressTable This table lists the IPv4 and IPv6 addresses. ipAddressPrefixTable This table lists the prefix information for all addresses. ipv6IpForwarding This flag indicates whether the target device is acting as a router to forward IPv6 packets. ipForwarding This flag indicates whether the target device is acting as a router to forward IPv4 packets. inetCidrRouteTable This IP routing table lists the routes for both IPv4 and IPv6 interfaces. If the target device supports the necessary versions of the IP-MIB and IP-FORWARD-MIB modules, the SNMP MIB2 sensor collects all the required information, and discovery completes. If the target device does not support the necessary 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 and CISCO-IETF-IP-FORWARDING-MIB modules are used to gather just the IPv6 information, 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)

Chapter 5. Network sensors

217

Sensor name that is used in the GUI and logs


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 are displayed as a Router in the Physical Infrastructure tree and in the Topology. All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v 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:1 v 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.

Model objects created


The sensor creates the following model objects: v net.Bridge v v v v v net.IpInterface net.IpRoute net.IpV4Address net.IpV6Address net.IpV4Router

v net.IpV6Router v net.L2Interface v sys.UnitaryComputerSystem v sys.OperatingSystem v sys.SnmpSystemGroup

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key To this: Authentication Protocol Password and Confirm Password

218

Application Dependency Discovery Manager: Sensors

Map from this: Private Authentication Description or Key

To this: Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Troubleshooting the sensor


This topic describes common problems that occur with the SNMP MIB2 sensor and presents solutions for those problems.

The sensor incorrectly identifies L3 switches as routers


Problem For SNMP devices that TADDM does not already know about, TADDM occasionally misidentifies L3 switches as routers. Solution Use the SNMP templates to provide TADDM with hints to correctly identify the switches and routers. See the Using topics in the IBM Tivoli Application Dependency Discovery Manager information center for information about how to use SNMP templates to assist TADDM with correct switch, router categorization.

The sensor fails doing an OS discovery


Problem The sensor fails doing an OS discovery. Solution Verify the credentials provided in the access list and check to ensure that SNMP is running on the TADDM client.

Chapter 5. Network sensors

219

220

Application Dependency Discovery Manager: Sensors

Chapter 6. Operating system sensors


Operating system sensors discover the operating systems that are running in the environment.

HP NonStop computer system sensor


The HP NonStop computer system sensor discovers the computer system that runs the HP NonStop OSS operating system. The sensor works only in Asynchronous discovery mode.

Sensor name that is used in the GUI and logs


HpNonStopComputerSystemSensor

Prerequisites
A discovery user needs to have access to both OSS and Guardian environment. An ASD script is executed from OSS environment. You can create ASD package by running the following command on one line:
dist/bin/makeASDScriptPackage.sh outputDir <output dir> --uname NONSTOP_KERNEL ipAddress <IP> --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 Generic Server Sensor that starts Level 3 sensors is not supported on the HP NonStop platform.

Model objects created


The sensor creates the following model objects: v core.LogicalContent v sys.hpnonstop.HpNonStop v sys.hpnonstop.HpNonStopComputerSystem

Asynchronous discovery support


The HP computer system sensor supports asynchronous discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration.

Access list configuration requirements


For asynchronous discovery, the access list is not used.

Copyright IBM Corp. 2008, 2012

221

Troubleshooting the sensor


Problems with the sensor might include unsuccessful discovery or incorrectly defined properties. However, you can recover from these problems.

General problems
Verify that the following sensors are enabled in the profile: v ASDPingSensor v ASDSensor v GenericComputerSystemSensor v HpNonStopComputerSystemSensor Verify that the ASD packages are available for a discovery in a directory defined by property com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory.

HP-UX computer system sensor


The HP-UX computer system sensor discovers a computer system that is running the HP-UX operating system. If a system is running HP-UX on an Itanium platform with virtualization support (HP Integrity Virtual Machines), the sensor discovers elements that are managed by the server.

Sensor name that is used in the GUI and logs


HpUxComputerSystemSensor

Prerequisites
For a VM Host system on an Itanium platform, the TADDM service account must have Execute permissions on the hpvmstatus and hpvminfo binary files. For a guest system on an Itanium platform, the TADDM service account must have Execute permissions on the hpvminfo binary files. The TADDM service account must have Execute permissions on the machinfo binary files.

Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v 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

Therefore, IP networks are not populated in the TADDM user interface. Discovery of IPv6 address of a guest system through a VM Host is not available for HP-UX on an Itanium platform. Discovery of IPv6 address of a VM Host through a guest system is not available for HP-UX on an Itanium platform.

222

Application Dependency Discovery Manager: Sensors

Guest systems that are running non-HP-UX operating systems are not created during discovery of the VM host systems.

Discovery of IPv6 interfaces and IPv6 routing and forwarding information


The sensor discovers IPv6 interfaces and IPv6 routing and forwarding information about target systems that are configured to support IPv6. TADDM runs discoveries against only IPv4 addresses. TADDM does not start a sensor against IPv6 addresses. 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 the prefix length value is unspecified or equals zero. The discovered IPv6 addresses are displayed in the TADDM user interface similarly to IPv4 addresses and are accessible using the TADDM API. Because IPv6 addresses use a prefix length value instead of an IPv4 netmask, only one of these values is populated for an IP address. The value depends on the address type.

Model objects created


The sensor creates the following model objects: v core.LogicalContent v sys.hpux.HpUx v sys.HpUxUnitaryComputerSystem v sys.SoftwareComponent

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. The HP-UX computer system sensor can be run using the ComputerSystem access credentials. 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 authentication to the target computer system. Typically, an account with non-root privilege can be used. However, some commands that TADDM uses during the discovery process can require privilege escalation. Typically, this escalation is done using the sudo command. For more information, see the topic Commands that might require elevated privilege in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center.

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:

Chapter 6. Operating system sensors

223

com.collation.platform.os.command.machinfo This property specifies the path to the machinfo command. If this property is not set, the default value of /usr/contrib/bin/machinfo is used. com.collation.discover.agent.command.kcmodule This property specifies the path to the kcmodule command. com.collation.platform.os.HpUxItanium.Model Used as a starting point for HpUx on Itanium. The default value is ia64. Change this property when the model command on HP-UX Itanium systems does not contain ia64 in the output. com.collation.discover.agent.command.hpvminfo This property specifies the path to the hpvminfo command. If this property is not set, the default value of /opt/hpvm/bin/hpvminfo is used. com.collation.discover.agent.command.hpvmstatus This property specified the path to the hpvmstatus command. If this property is not set, the default value of /opt/hpvm/bin/hpvmstatus is used. com.collation.platform.os.command.crontabEntriesCommand.HP-UX=crontab -l 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 set name 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=root This property is used to discover crontab entries for a specified user, use a comma-separated list to specify more than one user. You can specify this property as a scoped property by appending an IP address or a scope set name 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

Troubleshooting the sensor


This topic describes common problems that occur with the HP-UX computer system 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 unique identifier from the model command output. The Serial number attribute is not populated on Itanium by default. To enable the Serial number attribute, add the following entry in the collation.properties file on the TADDM server:
com.collation.discover.agent.sys.HpUxComputerSystemItaniumAgent.setSerialNumber=true

Hardware details are not displayed


Problem During a discovery through IBM Tivoli Monitoring, certain detailed information is not displayed for computer systems running the HP-UX operating system.

224

Application Dependency Discovery Manager: Sensors

Solution In the collation.properties file, add the |.*machinfo.* pattern to the end of the property:
com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*machinfo.*

IBM AIX computer system sensor


The IBM AIX computer system sensor discovers computer systems that run the IBM AIX operating system. In addition, workload partitioning (WPAR) in the IBM AIX 6.1 operating system is discovered by the sensor.

Sensor name that is used in the GUI and logs


AixComputerSystemSensor

Prerequisites
The TADDM user must have access to the entstat command on AIX target systems.

Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v 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:1 v 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 discovers WPARs by using the WPAR name and IP address. After running 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 the situation, where duplicate WPARs with the same name exist in the database. This limitation 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 the host name. In this case, TADDM does not request the host name from the DNS server and the name is not displayed.

Discovery of IPv6 interfaces and IPv6 routing and forwarding information


The sensor discovers IPv6 interfaces and IPv6 routing and forwarding information about target systems that are configured to support IPv6. TADDM runs discoveries against only IPv4 addresses. TADDM does not start a sensor against IPv6 addresses. 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 the prefix length value is unspecified or equals zero. The discovered IPv6 addresses are displayed in the TADDM user interface similarly to IPv4 addresses and are accessible using the TADDM API. Because IPv6 addresses use a prefix length value instead of an IPv4 netmask, only one of these
Chapter 6. Operating system sensors

225

values is populated for an IP address. The value depends on the address type.

Asynchronous and script-based discovery support


The IBM AIX computer system sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. See the TADDM Administrator's Guide for information about configuring for script-based discovery.

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 for nonscript-based discovery.

Limitations
Some function that is provided by the AIX computer system sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. Computer system templates and extensions are not supported. The following attributes are not discovered: v Level v BuildLevel v ServicePack

Model objects with associated attributes


The IBM AIX computer system sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about computer systems running the IBM AIX operating system and workload partitioning (WPAR) resources in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. sys.aix.Aix v AdminState v Admininfo v v v v v v v Description DisplayName Drivers InstalledSoftware LastModifiedBy Name PatchesInstalled

226

Application Dependency Discovery Manager: Sensors

v PrimaryOwner sys.AixSoftwareComponent v DisplayName v Group v LastModifiedBy v LastModifiedTime v ManagedSystemName v Name v Type sys.aix.AixUnitaryComputerSystem v Name v AdminState v Admininfo v v v v v CPUSpeed CPUType LastModifiedBy LastModifiedTime Manufacturer

v MemorySize v Model v Name v NumCPUs v PrimaryOwner v Type core.LogicalContent v Checksum v Configfile v Content v ContentType v FixedPath v URI core.Version v BuildLevel v Level v ServicePack net.L2Interface v AdminState v Broadcast v v v v ContextIp Description DisplayName Duplex

v Encapsulation v Guid
Chapter 6. Operating system sensors

227

v v v v v v v v v

HostInterface HwAddress Label ManagedSystemName Mtu Name ObjectType Parent Speed

dev.StorageExtent v AdminState v BasedOn v BlockSize v Capacity v ContextIp v Controller v Description v DeviceID v DisplayName v FreeSpace v ObjectType v Parent dev.StorageVolume v AdminState v BasedOn v v v v v v v v v v v v v v v v v BlockSize Capacity ContextIp Controller Description DeviceID DisplayName FreeSpace HostPaths IOGroup Label ManagedSystemName Name NumOfBlocks NumOfCylinders ObjectType Parent

sys.WPARComputerSystem v WparCPULimits

228

Application Dependency Discovery Manager: Sensors

v v v v v

WparCPUShares WparMemoryLimits WparMemoryShares WparOwner WparPerProcessVirtualMemoryLimit

v WparType

Configuring the sensor


Before running a discovery, you must configure the sensor. Edit the /etc/sudoers file on the AIX server and add the following line:
<TADDM_USER> ALL=NOPASSWD: ALL

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 use for either SSH key-based authentication or SSH login-based authentication to the target computer system. Typically, an account with non-root privilege can be used. However, some commands that TADDM uses during the discovery process can require privilege escalation. This escalation, can be done using the sudo command. For more information, see the topic Commands that might require elevated privilege in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the IBM AIX computer system sensor uses. The sensor uses the following entry in the collation.properties file: com.collation.discover.agent.command.lswpar.AIX=sudo lswpar The lswpar command requires administration privileges. com.collation.platform.os.command.crontabEntriesCommand.AIX=crontab -l 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 set name 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=root This property is used to discover crontab entries for a specified user, use a comma-separated list to specify more than one user. You can specify this property as a scoped property by appending an IP address or a scope set name to the property. The following example uses an appended IP address:
com.collation.platform.os.command.crontabEntriesUsers.AIX.1.2.3.4=root,build

Chapter 6. Operating system sensors

229

Troubleshooting the sensor


This topic describes common problems that occur with the IBM AIX computer system sensor and presents solutions for those problems.

Sensor does not discover WPARs


Problem The sensor is not able to discover WPAR. Solution To 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


Problem Some of the discovered WPARs do not display attribute values. Solution Verify if the WPARs present are in an active or defined state. For WPARs that are in a defined state, a limited number of attribute values are displayed.

IBM Hardware Management Console sensor


The IBM Hardware Management Console sensor discovers the IBM Hardware Management Console (HMC) and its managed systems.

Sensor name that is used in the GUI and logs


HmcSensor

Resources discovered by the sensor


The process for discovering an HMC is like discovering a standard computer system. The most important issues that impact discovery is connectivity and authentication. If the account configured in the TADDM access list can connect to the 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 with minimal information. Depending on the discovery scope, discovering a computer system (LPAR) can actually discovery 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.

230

Application Dependency Discovery Manager: Sensors

This instance is discovered just as a physical Linux or AIX computer system. There are no special TADDM sensors to discover these virtual computer systems any differently than the physical computer systems they emulate. The computer system (LPAR) discovered by the HMC is a shallow computer system. The following key attributes, which form the naming rule, are discovered: v v v v Manufacturer Model Serial number 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 adapters v Virtual NPIV adapters v Virtual target devices v Physical volumes v MPIO paths v HBAs You must use the Hmcoperator user to discover storage mapping information. With the discovery of HMC and the storage sensor discovery of LPARs, you can see a mapping between the LPAR disk and the virtual target device of a VIOS.

Limitations
To discover logical partitions (LPARs) and the HMC correctly, you must run the HMC sensor after a discovery of the LPARs.

Model objects with associated attributes


The IBM Hardware Management Console sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about IBM Hardware Management Console (HMC) and its managed systems in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. dev.BasedOnExtent v Source v Target sys.ComputerSystem v CPUCoresEnabled v CPUCoresInstalled v v v v v CPULimit CPUSpeed CPUType ChildSystem ContextIp
Chapter 6. Operating system sensors

231

v v v v v v v v v v v v v v v v v v

Description DesiredHugePages DesiredMemorySize DesiredProcessingUnits DesiredProcessors Devices DisplayName FileSystems Fqdn Functions Guid HostSystem IpInterfaces IsVMIDanLPAR L2Interfaces Label ManagedSystemName Manufacturer

v MaxHugePages v Memory v MemoryLimit v v v v v v v v v v v v MemorySize MinHugePages Model Name NumCPUs OSInstalled OSRunning ObjectType PrimaryMACAddress SerialNumber Signature StorageExtent

v SystemId v Type v UncappedWeight v VMID v Virtual sys.ControlSoftware v BuildLevel v ContextIp v v v v DisplayName Fixes Level MajorVersion

232

Application Dependency Discovery Manager: Sensors

v v v v

Modifier Name Release VersionString

dev.FCPort v DeviceID v TotalNpivPorts v AvailableNpivPorts v Parent v v v v v v Description PhysicalLocationCode Status PermanentAddress ChildPorts SecondaryAddress

sys.FileSystem v Parent v MountPoint sys.Function v Name v Parent sys.HMC v Systemp sys.LocalFileSystem v StorageExtent dev.MediaAccessDevice v v v v v Manufacturer Model Name SerialNumber Status

v Type dev.vios.MpioPath v Controller v Volume v Connection v Status dev.vios.NpivViosVirtualAdapter v ClientStatus v FcPorts dev.SCSIProtocolController v Name v Parent
Chapter 6. Operating system sensors

233

v v v v v

PhysicalLocationCode Client ServerSlotNumber TargetDevices ClientSlotNumber

v ObjectType v Description v EndPoints dev.SCSIProtocolEndPoint v Name v Parent v Description app.SoftwareFix v ControlSoftware dev.StorageVolume v Name v Parent v Type v IeeeUniqueVolumeName v Capacity v LUN v Pvid v NumStalePartitions v v v v SerialNumber SystemPState ViosUDID VolumeGroupName

v BasedOn v MpioPaths sys.SystemPComputerSystem v Architecture v AvailableSysProcUnits v CPUCoresEnabled v CPUCoresInstalled v CPUSpeed v v v v v v v CPUType ConfigurableNumSysHugePages ConfigurableSysProcUnits ConfigurableSystemMemory DeconfiguredSysProcUnits DeconfiguredSystemMemory HugePageSize

v Is5250ApplicationCapable v IsCoDMemoryCapable

234

Application Dependency Discovery Manager: Sensors

v v v v v v v v v v v v

IsCoDProcessorCapable IsI5OSCapable IsLHCACapable IsLHEACapable IsMicroPartitioningCapable IsSNIMsgPassingCapable IsVIOSCapable Manufacturer MaxNumProcessorsPerLPAR MaxsSharedProcessorPools MemoryAvailableForPartitions MemorySize

v MinProcessingUnitsPerVirtualProcessor v Model v SerialNumber dev.vios.VirtualTargetDevice v BackingDevice v Status

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 mentioned below. b. Password From the HMC management console, create a user account for the TADDM discovery user. The user account must be based on the hmcoperator role. In addition, the following command line tasks must be assigned to the user account: Managed System Required to use the lshwres and lssyscfg commands Logical Partition Required to use the lshwres, lssyscfg, and viosvrcmd commands HMC Configuration Required to use the lshmc command

Chapter 6. Operating system sensors

235

IBM Integrated Virtualization Manager sensor


The IBM Integrated Virtualization Manager sensor discovers IBM POWER processor-based systems managed by an Integrated Virtualization Manager (IVM).

Sensor name that is used in the GUI and logs


IvmSensor

Resources discovered by the sensor


The process for discovering an IVM is like a standard computer system. The most important issues that impact discovery is connectivity and authentication. If the account configured in the TADDM access list can connect to the IVM, the discovery 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) can actually 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 computer systems any differently than the physical computer systems they emulate. The computer system (LPAR) discovered by the IVM is a shallow computer system. The following key attributes, which form the naming rule, are discovered: v Manufacturer v Model v Serial number v LPAR ID, which are naming rule attributes. After discovery, TADDM merges the two instances into a single computer system.

Model objects created


The sensor creates the following model objects: v sys.ComputerSystem v sys.ControlSoftware v sys.IVM v sys.SystemPComputerSystem v sys.VIOS

Configuring the sensor


Before running a discovery, you must configure the sensor.

236

Application Dependency Discovery Manager: Sensors

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 TADDM discovery user with the View Only role.

IBM i computer system sensor


The sensor discovers the IBM i operating system, which is used on the IBM Power Systems family of servers and is the next generation of the IBM i5/OS operating system and the IBM OS/400 operating system.

Sensor name that is used in the GUI and logs


I5OSComputerSystemSensor

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 PASE programs. v The IBM Toolbox for Java, which is a library of Java classes that give Java programs 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 30 v PASE: 5770SS1 option 33 Note: In IBM i 7.1, the licensed program product JC1 (IBM Toolbox for Java) is no longer provided as a separate product. Instead, it is included as part of 5770SS1 option 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 30 v PASE: 5761SS1 option 33 v IBM Toolbox for Java: 5761JC1 For IBM i 5.4 and i5/OS V5R3, you need the following versions of the required software:
Chapter 6. Operating system sensors

237

v v v v

IBM Portable Utilities for i5/OS: 5733SC1 *BASE and option 1 Qshell: 5722SS1 option 30 PASE: 5722SS1 option 33 IBM Toolbox for Java: 5722JC1

Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v 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

Therefore, IP networks are not populated in the TADDM user interface. TADDM does not support the discovery of IBM i systems when using public key infrastructure (PKI) authentication. To initialize a connection between the TADDM server and an IBM i system, you must use a user name and a password.

Model objects created


The sensor creates the following model objects: v core.LogicalContent v dev.MediaAccessDevice v sys.i5OS.I5OperatingSystem v sys.i5OS.I5OSSoftwareComponent v sys.i5OS.I5Profile

Configuring the access list


This topic describes the access details that you require, depending on your configuration. Sufficient access privileges are required that allow users to discover the system: v Privilege class: User v System privileges: All object access is required to discover all user profiles on the system. Save/restore

IPSO computer system sensor


The IPSO computer system sensor discovers Nokia firewall devices running the IPSO operating system.

Sensor name that is used in the GUI and logs


IPSOComputerSystemSensor

238

Application Dependency Discovery Manager: Sensors

Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v 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

Therefore, IP networks are not populated in the TADDM user interface.

Model objects created


The sensor creates the following model objects: v core.LogicalContent net.Firewall v sys.Function v sys.ipso.ipso v sys.ipso.IPSOUnitaryComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 authentication to the target system.

Linux computer system sensor


The Linux computer system sensor discovers computer systems running the Linux operating system.

Sensor name that is used in the GUI and logs


LinuxComputerSystemSensor

Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v 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:1 v 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.

Chapter 6. Operating system sensors

239

Discovery of IPv6 interfaces and IPv6 routing and forwarding information


The sensor discovers IPv6 interfaces and IPv6 routing and forwarding information about target systems that are configured to support IPv6. TADDM runs discoveries against only IPv4 addresses. TADDM does not start a sensor against IPv6 addresses. 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 the prefix length value is unspecified or equals zero. The discovered IPv6 addresses are displayed in the TADDM user interface similarly to IPv4 addresses and are accessible using the TADDM API. Because IPv6 addresses use a prefix length value instead of an IPv4 netmask, only one of these values is populated for an IP address. The value depends on the address type.

Model objects created


The sensor creates the following model objects: v core.LogicalContent v sys.linux.Linux v sys.LinuxUnitaryComputerSystem v sys.SoftwareComponent v sys.zOS.ZSeriesComputerSystem v sys.zOS.LPAR v sys.zOS.ZVMGuest

Asynchronous and script-based discovery support


The Linux computer system sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. See the TADDM Administrator's Guide for information about configuring for script-based discovery.

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 for nonscript-based discovery.

Limitations
Some function that is provided by the Linux computer system sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. The following functions are not supported: v Computer system templates and extensions v Deep Level 2 discovery

240

Application Dependency Discovery Manager: Sensors

v Discovery on Linux systems that are not x86 systems The following attributes are not supported for the L2Interface model object: v AutoNegotiation v Speed v Duplex

Configuring the sensor


Before running a discovery, you must configure the Linux computer system sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 authentication to the target computer system. Typically, an account with non-root privilege can be used. However, some commands that TADDM uses during the discovery process may require privilege escalation (typically done using the sudo command). For more information, see the topic Commands that might require elevated privilege in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the Linux computer system sensor uses. The sensor uses the control program vmcp command to discover a Linux virtual system running on a z/VM operating system. For each Linux virtual system, specify the path for the vmcp command in the collation.properties file. com.collation.discover.agent.command.vmcp.Linux.1.2.3.4={command path} This value specifies the path name of the vmcp command for different Linux virtual systems with different IP addresses. For example, to specify the path of the vmcp command in the /sbin directory, on a Linux host with IP address 192.168.1.2, add the following entry to the collation.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 set name 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=root This property is used to discover crontab entries for a specified user, use a comma-separated list to specify more than one user. You can specify this property as a scoped property by appending an IP address or a scope set name to the property. The following example uses an appended IP address:
com.collation.platform.os.command.crontabEntriesUsers.Linux.1.2.3.4=root,build

Chapter 6. Operating system sensors

241

Troubleshooting the sensor


This topic describes common problems that occur with the Linux computer system sensor and presents solutions for those problems.

The sensor fails with a command failed to run error


Problem The following message is displayed:
Error Message: CTJTD0431E: The following command failed to run or returns a blank value: sudo /sbin/vmcp q userid | awk print{3}.

The command vmcp q userid has failed to run or returns a blank value on the target Linux virtual system running on a z/VM operating system. Solution This 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 the collation.properties file. See the topic Configuring the collation.properties file entries for details. v Verify that the system name is configured on the z/VM system, the system name cannot be blank. v If the vmcp tool is not installed on the Linux virtual system, you must load it. To load the vmcp device driver, issue the modprobe vmcp command on the Linux guest. v Verify that the sudo command is available. To verify run the following command 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 command to 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 the host system on the z/VM operating system, it is not necessary to run the vmcp command. You can use the externalized command property (com.collation.discover.agent.command.vmcp.Linux=) in the collation.properties file to set the host system value to a dummy value. You must be able to parse the externalized command with the following command 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 virtual systems is set to zVMHost instead of the actual host system name.

242

Application Dependency Discovery Manager: Sensors

z/VM guests can be duplicated after multiple discoveries of the same Linux virtual system
Problem Duplicates can occur if the command vmcp q userid returns a blank value on the target Linux virtual system running on a z/VM operating system. Solution You must manually merge these duplicates.

OpenVMS computer system sensor


The OpenVMS computer system sensor discovers computer systems running the OpenVMS operating system.

Sensor name that is used in the GUI and logs


OpenVmsComputerSystemSensor

Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v 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:1 v 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.

Model objects created


The sensor creates the following model objects: v core.LogicalContent v sys.openvms.OpenVms v sys.openvms.OpenVmsUnitaryComputerSystem

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 authentication to the target computer system.

Solaris computer system sensor


The Solaris computer system sensor discovers computer systems that are running the Solaris operating system.

Chapter 6. Operating system sensors

243

If the target system is a Solaris 10 global zone that has local zones with a status of running, the sensor creates a computer system object for each zone and populates the following attributes: v v v v v v v name virtual type VMID host system signature processor name

To retrieve operating system details for the local zone, you must add the IP address of the local zone to the discovery scope.

Sensor name that is used in the GUI and logs


SunSparcComputerSystemSensor

Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v 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:1 v 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 discovers the number of physical processors if one of the following commands are present on the target system: v psrinfo -p v prtconf and kstat -m cpu_info. The kstat command must return implementation statistics. The sensor discovers the number of processor cores when the command kstat -m cpu_info is present on the target system. The kstat command must return core_id statistics. For the sensor to discover information about promiscuous mode on the Solaris operating system, the following command must be available for the network interface on the target system:
kstat network_interface_name | grep promisc

Discovery of IPv6 interfaces and IPv6 routing and forwarding information


The sensor discovers IPv6 interfaces and IPv6 routing and forwarding information about target systems that are configured to support IPv6. TADDM runs discoveries against only IPv4 addresses. TADDM does not start a sensor against IPv6 addresses. For DNS lookups, TADDM uses either the IPv4 or the IPv6 addresses.

244

Application Dependency Discovery Manager: Sensors

TADDM does not populate the net.IpNetwork attribute on an IPv6 interface if the prefix length value is unspecified or equals zero. The discovered IPv6 addresses are displayed in the TADDM user interface similarly to IPv4 addresses and are accessible using the TADDM API. Because IPv6 addresses use a prefix length value instead of an IPv4 netmask, only one of these values is populated for an IP address. The value depends on the address type.

Model objects created


The sensor creates the following model objects: v core.LogicalContent v sys.sun.Solaris v sys.sun.SolarisPackage v sys.SunSPARCUnitaryComputerSystem

Asynchronous and script-based discovery support


The Solaris computer system sensor supports asynchronous and script-based discovery.

Sensor configuration requirements


For asynchronous discovery, the sensor requires no configuration. See the TADDM Administrator's Guide for information about configuring for script-based discovery.

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 for a nonscript-based discovery.

Limitations
Some function that is provided by the Solaris computer system sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. The following functions are not supported: v Computer system templates and extensions v Deep Level 2 discovery v Zone discovery The following attributes are not supported: v L2Interface AutoNegotiation Speed Duplex v ComputerSystem (global zone) Virtual
Chapter 6. Operating system sensors

245

ChildSystem VMID CPUCoresInstalled CPUDiesInstalled v ComputerSystem (local zone) Virtual HostSystem VMID CPUCoresInstalled CPUDiesInstalled

Configuring the sensor


Before running a discovery, you must configure the Solaris computer system sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 authentication to the target computer system. Typically, an account with non-root privilege can be used. However, some commands that TADDM uses during the discovery process can require privilege escalation (typically done using sudo command). For more information, see the topic Commands that might require elevated privilege in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the Solaris computer system sensor uses. The sensor uses the following entry in the collation.properties file: com.collation.platform.os.command.crontabEntriesCommand.SunOS=crontab -l 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 set name 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=root This property is used to discover crontab entries for a specified user, use a comma-separated list to specify more than one user. You can specify this property as a scoped property by appending an IP address or a scope set name to the property. The following example uses an appended IP address:
com.collation.platform.os.command.crontabEntriesUsers.SunOS.1.2.3.4=root,build

246

Application Dependency Discovery Manager: Sensors

Troubleshooting the sensor


This topic describes common problems that occur with the Solaris computer system sensor and presents solutions for those problems.

The sensor does not start


Problem The TADDM discovery user does not have authority to run the ps command with the full command-line arguments required to start the sensor. Solution Complete one of the following tasks: v Set the sticky bit for the ps command, using the following command:
chmod u+s /usr/ucb/ps

Note: The sticky bit might be overwritten by the operating system if a patch is applied that updates the ps command. v Configure the ps command to run with sudo access for the TADDM discovery 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 has been granted to the TADDM discovery user by running the following command on the target system:
sudo ps

Discovery fails when carrying out a discovery through IBM Tivoli Monitoring
Problem During a discovery through IBM Tivoli Monitoring, the discovery fails because of a problem running the command cd $HOME;LANG=C zonecfg -z s8-zone info. Solution In the collation.properties file, add the |.*zonecfg.* pattern to the end of the property:
com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*zonecfg.*

Solaris zones generic sensor


The Solaris zones generic sensor discovers applications running on Solaris local zone systems. The sensor results are used to start specific application sensors, such as IplanetServerSensor, WeblogicServerSensor, or CustomServerSensor, which discover application servers that TADDM does not automatically categorize.
Chapter 6. Operating system sensors

247

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 zone system is used to start the ZonesGenericSensor. This is because the lsof tool is unavailable on local zones. To retrieve all operating system details of the local zone, you must include the IP address of the local zone in the discovery scope.

Sensor name that is used in the GUI and logs


ZonesGenericSensor

Prerequisites
The credentials for local and global zones must be entered in the access list (either using SSH key-based authentication or SSH login-based authentication).

Security issues
To correctly discover applications running on a local zone, the TADDM service account in the local and global zones must have access to the ps command with full command-line arguments. Use the following method, to ensure access when the root account or the setuid bit 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 dependency between the application server and the NFS Server is not created. v When WebLogic 8 (all releases) managed and admin servers are running on local zones, the runtime information is stored using the CustomAppServerSensor. The CustomAppServerSensor is started by the WeblogicVersionSensor. You must include all local and global zone IP addresses in the discovery scope. In addition, ensure that the custom server list contains at least one template to match the WebLogic command line and that the custom server is enabled. v When running a discovery through an anchor server, include the IP addresses of the 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 on a local zone.

Model objects created


The sensor creates the following model object: v sys.RuntimeProcess

Sun Fire SysControl sensor


The Sun Fire SysControl (SC) sensor discovers domains that are configured on Sun Fire systems.

248

Application Dependency Discovery Manager: Sensors

The following information is obtained from the system controller on the Sun Fire system: v Remote configuration administration operations v Board assignments and board status v Current usage statistics for Capacity on Demand (COD) resources v System board devices and resource usage information v System controller (SC) failover status or role v Platform type, board available component list, the domain state for each domain, and Capacity on Demand (COD) information

Sensor name that is used in the GUI and logs


SysControlSensor

Security issues
The TADDM service account must have platform administrator privileges, which means that the account is a member of the UNIX group platadmn. Any user who is a member of the platadmn group has privileges to run the following System Management Services (SMS) commands: v v v v v rcfgadm showboards showcodusage showdevices showfailover

v showplatform

Model objects with associated attributes


The Sun Fire SysControl (SC) sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about domains that are configured on Sun Fire systems in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. phys.physpkg.Board v v v v DisplayName Name PhysicalPackage RelativePosition

sys.sun.DynamicSystemDomain v Board v DisplayName v Fqdn v HostSystem v IsVMIDanLPAR v Model v Name v NumCPUs


Chapter 6. Operating system sensors

249

v SerialNumber v Type v Virtual sys.sun.SunFireComputerSystem v ChildSystem v Devices v DisplayName v Manufacturer v Model v Name v SerialNumber v Type

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 authentication to the target computer system. An account with platform administrator privileges must be used.

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.path.SunOS This 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, enter the 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=1200000 This value specifies the time interval in milliseconds to allow the command to run.

250

Application Dependency Discovery Manager: Sensors

Troubleshooting the sensor


This 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


Problem During a discovery, the sensor fails with a timeout error. Solution In the etc/collation.properties file, add the following property, where value 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


Problem The following message is displayed:
Error Message: CTJTD3021E: The sensor fails in a remote server: discoverSystemController: getModelObject failure

Solution In the etc/collation.properties file, add the path configuration for command 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 sensor


The Tru64 computer system sensor discovers computer systems running the Tru64 UNIX operating system.

Sensor name that is used in the GUI and logs


Tru64ComputerSystemSensor

Prerequisites
The sensor requires the following software: v sudo command tool v lsof diagnostic tool Install both tools in the same path as defined in the access list for accessing the Tru64 UNIX computer system. This installation must be done on each Tru64 UNIX computer system to be discovered. The most tested versions are sudo-1.6.8p9 and lsof-4.78, however, other versions are likely to work, except in the case where the specific package does not support Tru64 UNIX. To get sudo-1.6.8p9 and lsof-4.78, go to the following Web sites: v For sudo-1.6.8p9: http://www.gratisoft.us/sudo/download.html v For lsof-4.78: http://freshmeat.net/projects/lsof/?branch id=6029&release id=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 a particular package has restrictions, TADDM is affected by those restrictions.
Chapter 6. Operating system sensors

251

Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v 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

Therefore, IP networks are not populated in the TADDM user interface.

Model objects created


The sensor creates the following model objects: v core.LogicalContent v sys.ComputerSystem v sys.tru64.Tru64

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring non-root user to run the sensor


You must add the users credentials for non-root users. Edit the /etc/sudoers file on the Tru64 UNIX computer system and add the following 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 being discovered. For example, to enable the user taddmusr to run the command on any Tru64 UNIX computer system, enter the following line:
taddmusr ANY = NOPASSWD: /sbin/hwmgr

For example, to enable the user taddmusr to run the /sbin/hwmgr command on a specific 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 UNIX computer system: /sbin/hwmgr and /usr/sbin/ifconfig.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 authentication to the target computer system.

252

Application Dependency Discovery Manager: Sensors

Typically, an account with non-root privilege can be used. The commands that are used by the Tru64 computer system sensor carrying out the discovery can require privilege escalation. Typically, this escalation is done by setting the file access permissions using the sudo command. For more information, see the topic Commands that might require elevated privilege in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center.

Troubleshooting the sensor


This topic describes common problems that occur with the Tru64 computer system sensor and presents solutions for those problems.

Storage error messages displayed


Problem Storage error messages. Solution In this case, the Tru64 UNIX system issues a message with an Other IP Device status. Check the locations and permissions on the dependencies and run the discovery again.

VMware ESX computer system sensor


The VMware ESX computer system sensor discovers VMware ESX servers.

Sensor name that is used in the GUI and logs


VmwareComputerSystemSensor

Elements discovered by the sensor


Discovering the VMware ESX server (host machine) runs as it does for any other operating system. The most important issues that impact discovery is connectivity and authentication. If the account configured in the TADDM access list can connect to the VMware ESX server target, the discovery is successful. For VMware ESX 2.5, discoveries are launched using commands. For VMware ESX 3.0 and 3.5, commands are run over ssh and VMware APIs are used to get VMware ESX attributes and details about virtual machines. Discovering the Virtual Machines (guest machines) actually discovers two instances of a VM, a physical instance and a virtual instance. After discovery, TADDM merges these two instances. The result is a single instance with all the attributes of a physical machine, but with the indication that it is virtual. In the XML output of the 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 a computer system icon that is blue and transparent. The physical instance is discovered by the normal TADDM sensor for the particular guest operating system, such as Linux. It is discovered just like a

Chapter 6. Operating system sensors

253

physical machine, which includes finding typical devices and attributes. No special TADDM sensors are required to discover these virtual machines any differently than the physical machines they emulate. The virtual instance is discovered by the VMware ESX sensor. It primarily uses configuration files (.vmx) and commands on the VMware ESX server to discover a shallow 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 instance v 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 to match its domain name. This virtual instance is populated with all the attributes that a similar physical machine would have. In addition, it has data and relationships regarding the host ESX server, a virtual attribute that gets set to true, and a VMID attribute that gets set to the one specified in the .vmx configuration file. As long as the TADDM server has connectivity and authentication to the VM, this scenario does not present any problems. v VM-only: When discovering a scope that contains only the VM, it shows up as a physical machine with typical attributes, except that VMware intentionally overrides some model and manufacturer data. Therefore, it is possible to determine if a machine is virtual by examining some attributes. However, the icon is the one used for physical computers, and the virtual attribute is not set to true. To ensure all FQDN information about a VM is collected, you must have VMware Tools installed on the VM.

Prerequisites
For VMware ESX server version 3 and 4, the web Access service (service vmware-webAccess) must be running on the target and the port that it runs on must be accessible from the discovery server or its anchor.

Security issues
To discover VMware ESX 3.x, you must set read-only permissions for the non-root TADDM service account in the VMware ESX console or use the root user for discovery. For more information see the VMware community board: http:// www.vmware.com/community/thread.jspa?messageID=454784

254

Application Dependency Discovery Manager: Sensors

Limitations
VMware vCenter servers are not discovered by the VMware ESX computer system sensor. If you must discover these servers, use the VMware Virtual Center server sensor. All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v 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:1 v 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. For VMware ESX server version 2.5 (all releases), you can discover virtual systems only that are running.

Model objects created


The sensor creates the following model objects: v core.LogicalContent v net.IpInterface v net.L2Interface v process.CPUResourcePool v process.MemoryResourcePool v v v v v v v v v v v v v process.NetworkAdapterResourcePool relation.AllocatedTo relation.DonatedTo sys.CPU sys.darwin.Darwin sys.darwin.DarwinUnitaryComputerSystem sys.dos.Dos sys.dos.DosUnitaryComputerSystem sys.DNSResolveEntry sys.FileSystem sys.freebsd.FreeBSD sys.freebsd.FreeBSDUnitaryComputerSystem sys.linux.Linux

v sys.linux.LinuxUnitaryComputerSystem v sys.Memory v v v v v sys.netware.Netware sys.netware.NetwareUnitaryComputerSystem sys.OperatingSystem sys.sun.Solaris sys.sun.SunSPARCUnitaryComputerSystem

v sys.UnitaryComputerSystem v sys.vmware.VmwareESX
Chapter 6. Operating system sensors

255

v sys.vmware.VmwareUnitaryComputerSystem v sys.windows.WindowsComputerSystem v sys.windows.WindowsOperatingSystem

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring non-root user to run the sensor


You must add the users credentials to the Read-Only role by using the VMware Infrastructure Client for non-root users. By default, non-root users do not have permission to run VMware ESX discoveries. To enable this functionality for non-root users, you must add them to the Read-Only role in the VMware client. This task does not need to be performed for the root user. To add a non-root user to the Read-Only role, complete the following steps: 1. Using VMware Infrastructure Client, log in to the VMware ESX server using root credentials. 2. Click the Permissions tab. 3. Right-click in the Permissions pane and click Add Permissions. The Assign Permissions window is displayed. 4. In the Assigned Role area, select Read-Only from the list. 5. In the Users and Groups area, click Add. The Select User window is displayed. 6. Select the non-root user to which you want to grant additional permissions. Click Add. Click OK. 7. To apply the changes, click OK.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. Typically, an account with non-root privilege can be used. However, some commands that TADDM uses during the discovery process can require privilege escalation (typically done using the sudo command). For more information, see the topic Commands that might require elevated privilege in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center.

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.platform.os.command.osVersion.Vmware The command used to determine the version of VMware. The default value is /usr/bin/vmware v. com.collation.platform.os.command.vmwareCmd The command to perform operations on the virtual machine. The default value is /usr/bin/vmware-cmd.

256

Application Dependency Discovery Manager: Sensors

Troubleshooting the sensor


This topic describes common problems that occur with the VMware ESX computer system sensor and presents solutions for those problems.

Some attribute information is not displayed in the Details panel of the VMware server
Problem The attributes Model, Manufacturer, and Serial Number are blank in the Details panel of the VMware ESX server. (VMware ESX 2.x only) Solution The dmidecode command is not installed or not working properly. This command for the Linux kernel operating systems is not installed by default on VMware ESX 2.x as it is in 3.x versions. This is not required for the discovery. However, if the fields Model, Manufacturer, and Serial Number are required, TADDM needs the dmidecode command installed on the VMware ESX server. For more information see: http://www.nongnu.org/dmidecode/.

Duplicate VMs are created


Problem After discovery, certain VMs seem to have duplicates. Solution TADDM discovers two instances of a VM, one physical and one virtual. If they cannot be reconciled to the same specific machine, two instances can exist in the database with similar attributes. These are not duplicates, but two separately discovered instances of the same VM. This distinction is key to troubleshooting the problem, and there are several things to check, starting with TADDM, moving into the VMware environment, and then finally troubleshooting the general network environment. Issues related to a pre-existing instance or database The first item to check when troubleshooting a reconciliation problem is the database. If the VM has made the transition to a new VM, the old VM might not be able to reconcile. The old instance can be deleted, preferably before restarting the discovery. 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 is feasible in the environment, it can be helpful to drop and re-create the TADDM database between discovery runs. Then run a new discovery and see if the duplicates still exist. <primaryMACAddress> attribute The main reason that two instances of a VM cannot be reconciled is that they have different values in the <primaryMACAddress> attributes. To determine this value for each instance, it is necessary to export the objects of type ComputerSystem from the TADDM database 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
Chapter 6. Operating system sensors

257

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 all instances of the ComputerSystem class is generated. Look for the short name of the duplicate instances and scroll down to the attribute named <primaryMACAddress>. If the value is different for the two instances, it is necessary to troubleshoot the MAC address assignments in the configuration file on the server, on the VM itself, or both. VM configuration If a VM is configured in NAT or 'host only' mode, the VMwareESX sensor discovers the virtual instance, but the physical instance is not discovered. VM configuration files on the ESX host server The TADDM VMwareESX sensor gathers information from configuration files for each VM to be discovered. These configuration files can be located with the following ESX command:
vmware-cmd l (this is a lower-case L)

This command lists the configuration file for each VM known to the ESX server, indicated by the .vmx extension. These files are in XML format and are not case-sensitive. View the information in the configuration file for the VM that has duplicate instances. Validate the information for each interface to ensure that the MAC address 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 itself On the VM, there is a command that displays the information for each networking interface. On non-Windows systems, the command is ifconfig. On Windows the command is ipconfig. Examine the output and validate the interface/MAC pairings against the ESX configuration file. You can also verify that each interface is working by pinging the associated IP address. Try the discovery again.

258

Application Dependency Discovery Manager: Sensors

Recent changes in a VM or movement from one ESX server to another If a VM has been migrated from one ESX server to another, it is possible that the configuration file was changed and that can affect discoveries. If the lines that contain generatedAddress get deleted it can affect discoveries. When migrating VMs in a VirtualCenter environment, any VM with a generated MAC address is going to change it. If there is an existing VM on the ESX server that can be successfully discovered, use the configuration file for that VM as an example and look for any lines that might have been deleted. The ESX server where the VM originated can also be specified as a target in a scope to see if the VM discovers correctly on that ESX server. If there are lines that have been deleted or modified during migration, add or correct them and run the discovery again. Name resolution If the VM cannot resolve to a single machine on the network, it can end up in TADDM as two separate instances. If the VM has multiple interfaces, and all interfaces are visible on the network, multiple valid instances can be found. It might not be possible to merge 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 short name a few times from the VM itself, the ESX server, and the TADDM server. All the responses must match. If they return different responses, modify the name service or hosts files until the results are consistent. Try the discovery again. General network connectivity & routing There are global networking factors to consider in troubleshooting TADDM discoveries. As it relates to VMware discoveries, a firewall or other networking consideration such as SSH might partially obscure discovery of either the ESX server or the VM. If the VM is discovered correctly by the VMware sensor, it is displayed with only a short name label under the Physical Infrastructure: Overview > Systems Tier > Virtual Systems > VMware ESX The VM itself appears only as an object under the heading of Other Ip Device or Other Computer System. In the case where only the VM is discovered correctly by the OS sensor, it is displayed as the appropriate type of Computer System. The virtual instance is not displayed, and the ESX server might not be displayed either. Correct the routing and firewall configuration until the TADDM server can ping and SSH to the ESX server and directly to each of the VMs, then try the discovery again.

Duplicate VMware ESX servers are created


Problem VMware ESX servers (Version 2.5 (all releases)) seem to be duplicated. This
Chapter 6. Operating system sensors

259

problem occurs when a sequential discovery is run by using the VMware ESX computer system sensor followed by the VMware Virtual Center server sensor. Solution You must manually merge duplicated VMware ESX servers. The TADDM User's Guide (or the TADDM Using topics) contains information about using the Data Management Portal, including information about discovery tasks, and how to manually merge discovered configuration items.

VMware ESX server configuration items (CIs) are missing


Problem The CI for the VMware ESX servers are missing or show erroneous information such as processor and memory information. Solution For VMware ESX server version 3 and 4, ensure that the web Access service (service vmware-webAccess) is running on the target. The port that it runs on must be accessible from the discovery server or its anchor.

Windows computer system sensor


The Windows computer system sensor discovers computer systems running Microsoft Windows operating systems.

Sensor name that is used in the GUI and logs


WindowsComputerSystemSensor

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 version 2.0 or higher must be installed on the target Windows systems. v Windows Scripting Host (WSH) 5.6 or higher must be installed on the target Windows systems. Windows Scripting Host is installed with Internet Explorer 6 Service Pack 1 or higher.

Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v 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

Therefore, IP networks are not populated in the TADDM user interface.

260

Application Dependency Discovery Manager: Sensors

Discovery of IPv6 interfaces and IPv6 routing and forwarding information


The sensor discovers IPv6 interfaces and IPv6 routing and forwarding information about target systems that are configured to support IPv6. TADDM runs discoveries against only IPv4 addresses. TADDM does not start a sensor against IPv6 addresses. 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 the prefix length value is unspecified or equals zero. The discovered IPv6 addresses are displayed in the TADDM user interface similarly to IPv4 addresses and are accessible using the TADDM API. Because IPv6 addresses use a prefix length value instead of an IPv4 netmask, only one of these values is populated for an IP address. The value depends on the address type.

Model objects created


The sensor creates the following model objects: v dev.MediaAccessDevice v sys.DNSResolveEntry v sys.SoftwareComponent v sys.windows.WindowsComputerSystem v sys.windows.WindowsOperatingSystem v sys.windows.WindowsService

Configuring the sensor


Before 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 WMI Provider on all target Windows systems during the discovery process.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 all WMI objects on that machine. This account can be a local account or a domain account. The service account must be created on the Windows gateway and all target Windows computer systems. 2. Access list entries must be created for the Windows computer systems (gateway and the target Windows systems). When specifying a Windows domain user account for an access list entry, the domain name and user name must be separated by a backslash (\) as shown in the following example: DOMAIN\username.

Chapter 6. Operating system sensors

261

3. TADDM also supports SNMP-based discovery of Windows systems. To support SNMP-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 entries


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

Gateway-based or SSH-based discovery properties


com.collation.AllowPrivateGateways=true The default value is true. This property specifies whether a Windows computer system can be discovered using SSH or IBM Tivoli Monitoring connections without requiring an intermediate gateway. The default is to allow SSH or IBM Tivoli Monitoring connections to Windows systems. If the value is set to false, only gateway-based discovery can be used. com.collation.PreferWindowsSSHOverGateway=false The default value is false. This property specifies whether to use SSH rather than gateway-based discovery if a Windows computer system supports SSH. Even if a Windows computer system supports SSH, the default value for this property indicates that gateway-based discovery is used. This property is ignored if com.collation.AllowPrivateGateways=false.

WMI-related properties
TADDM relies on Windows Management Instrumentation (WMI) to discover Windows computer systems. TADDM can be configured to restart the WMI service if a problem occurs with WMI. If the WMI service is restarted, all WMI-dependent services that were running before the restart are also restarted. com.collation.platform.os.WindowsOs.AutoDeploy=true The default value is true, which indicates that TADDM can automatically install the WMI provider. Setting the value to false indicates that you can manually deploy the WMI provider. Manual deployment is not supported but can be used for troubleshooting. The following TADDM server properties control the restarting of WMI. Note: The default value for WMI restart is false. Setting the values of the following properties to true might provide more reliable Windows discovery, but you must also consider the potential negative impact of the WMI service being temporarily stopped and restarted. com.collation.RestartWmiOnAutoDeploy=false Restart WMI if a WMI error occurs during automatic deployment of the TADDM WMI Provider. com.collation.RestartWmiOnAutoDeploy.1.2.3.4=false Restart WMI if a WMI error occurs during automatic deployment of the TADDM WMI Provider.

262

Application Dependency Discovery Manager: Sensors

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.

Troubleshooting the sensor


This topic describes common problems that occur with the Windows computer system sensor and presents solutions for those problems.

Problem with WMI


Problem Windows Management Instrumentation (WMI) fails on the system that is to be discovered, which causes discovery to fail. Solution Restarting WMI might correct the problem. Use the following commands to restart WMI:
net stop winmgmt net start winmgmt

If restarting WMI does not correct the problem, use the following Microsoft utilities to troubleshoot WMI problems: WMIDiag The 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 that WMI is working correctly. Scriptomatic The Scriptomatic utility is available at the following Web site: http://www.microsoft.com/downloads/ details.aspx?familyid=09dfc342-648b-4119-b7eb-783b0f7d1178 &displaylang=en The Scriptomatic utility can be used to generate WMI queries that are similar to those used by TADDM. The following WMI classes are some that TADDM queries: v Win32_Process v Win32_OperatingSystem v Win32_WMISetting v Win32_ComputerSystem Verify that these classes can be queried using the Scriptomatic utility locally on the target system and remotely from the gateway.

Problem with deployment of WMI provider


Problem For discovery of Windows systems, TADDM deploys a WMI provider to each target system to enable agentless discovery. Sometimes, problems occur with this deployment.

Chapter 6. Operating system sensors

263

Solution The following files comprise the WMI provider and are located on the TADDM server in the $COLLATION_HOME/lib/ms/gateway directory: TaddmWmi.dll The WMI provider, which runs TaddmWmi.exe for functionality TaddmWmi.mof Specifies the new WMI methods that are provided by the WMI provider (TaddmWmi.dll) TaddmWmi.exe Called by the WMI provider (TaddmWmi.dll) to run a command TaddmWmi.pdb Contains 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 uses either 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

To troubleshoot WMI or access-related problems, you can run the TADDM WMI installation provider manually. To manually install the provider using the TaddmTool program on the Windows gateway, enter the following commands: 1. cd WINDOWS\temp\taddm.nnnn, where nnnn is a string that identifies the TADDM gateway directory. If fixes have been applied to the TADDM server, more than one gateway directory might be present. The identifier string can be found in the DiscoveryManager.log file after the following 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 is the IP address of the target system

WMI access denied errors


Problem You have WMI access denied errors. Solution Refer to Appendix F of the Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking v1.1, an IBM Redbooks publication, at http://www.redbooks.ibm.com/ abstracts/SG247264.html.

264

Application Dependency Discovery Manager: Sensors

WMI process creation errors


Problem WMI process creation fails with an access error during provider installation. There might be a problem with the Windows Replace a Process Level Token privilege not being granted to the required accounts. Solution v This privilege should be granted to the LOCAL SERVICE and NETWORK SERVICE accounts. To verify this, complete the following steps: 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 Process Level Token privilege, try to add the discovery account to a group that has that privilege. Check to see if the Tivoli_Admin_Privileges group has the privilege. If it does, make the discovery account a member of that group.

The specified network name is no longer available


Problem If this error occurs, or if there is a problem copying files to the target during provider installation, there might be a problem connecting to the SMB (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 by opening 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 one of 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, complete the 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.

Chapter 6. Operating system sensors

265

If telnet succeeds, a firewall is causing the problem. Otherwise, there is a 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 applications running on those systems
Problem The slow discovery of Windows 2003 SP1 systems, or applications running on those systems, might be a result of a memory leak in the WMI service. Solution Ensure that the following hotfix, available from Microsoft, is installed: http://support.microsoft.com/kb/911262

Windows 2000 systems are not discovered


Problem If Windows 2000 systems are not discovered, the problem might be because an unsupported version of the netstat program installed on the target system. The netstat program is used to get TCP port information during discovery. Windows 2000 systems use a different version of the netstat program from the one installed on systems running later versions of Windows. Solution Ensure that the following hotfix, available from Microsoft, is installed: http://support.microsoft.com/kb/907980

266

Application Dependency Discovery Manager: Sensors

Chapter 7. Storage sensors


Storage sensors discover the storage that is used in the environment.

Fibre Channel switch sensor


The Fibre Channel switch sensor discovers Fibre Channel (FC) switches and information about FC ports.

Sensor name that is used in the GUI and logs


FCSwitchSensor

Model objects with associated attributes


The Fibre Channel (FC) switch sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about Fibre Channel switch resources in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. dev.FCPort v DisplayName v PortNumber v DeviceID v PermanentAddress v PortType v Speed relation.ConnectedTo v Source v Target storage.FCSwitch v Name v Description v WorldWideName v Model v Manufacturer v SerialNumber v Version sys.ControlSoftware v Name v VersionString

Configuring the sensor


Before running a discovery, you must configure the sensor.

Copyright IBM Corp. 2008, 2012

267

Configuring the discovery profile


This topic describes how to configure the discovery profile. The sensor is not enabled by default. To enable the sensor, you must create a discovery profile, and then enable the sensor from the new profile. The sensor requires, additional sensors to be enabled in the profile: v AnchorSensor v PingSensor v PortSensor v SessionSensor v SnmpMib2Sensor

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Troubleshooting the sensor


This topic describes common problems that occur with the Fibre Channel switch sensor and presents solutions for those problems.

Incomplete switch information discovered


Problem The sensor completes the discovery but does not collect all the details about the switches. Solution Verify 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)

268

Application Dependency Discovery Manager: Sensors

Host resources sensor


The host resources sensor uses the host resources MIB to discover operating system details 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 of memory and out of buffers problems.

Sensor name that is used in the GUI and logs


HostResourcesSensor

Limitations
File systems discovered by the sensor are not displayed in the user interface. This restriction applies to computer systems running on operating systems other than Windows operating system. Run the api.sh script to see the file systems discovered by this sensor.

Object identifiers (OIDs) that are used


The sensor uses the following high-level OIDs to retrieve the attributes: v Memory Size: .1.3.6.1.2.1.25.2.2.0 v Storage Table: .1.3.6.1.2.1.25.2.1.2 v Device Type: .1.3.6.1.2.1.25.3.1.1 v Media Access Device: .1.3.6.1.2.1.25.3.2.1.1 v Installed Software: .1.3.6.1.2.1.25.6.3.1.1

Model objects created


The sensor creates the following model objects: v dev.MediaAccessDevice v sys.ComputerSystem sys.OperatingSystem v sys.FileSystem v sys.SoftwareComponent

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) To this: Authentication Protocol
Chapter 7. Storage sensors

269

Map from this: MD5 Secret Key Private Authentication Description or Key

To this: Password and Confirm Password Private Password

You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.

Host storage sensor


The host storage sensor discovers the storage that is attached to a host computer system, including storage area network (SAN) storage. This sensor extends the storage discovery that is provided by the storage sensor. The host storage and storage sensors discover the same storage resources, for example, disks, partitions, logical volumes, physical volumes, and file systems. The host storage sensor also discovers the following storage resources: v Fibre Channel (FC) volumes v FC ports v Host bus adapters

Sensor name that is used in the GUI and logs


HostStorageSensor

Security issues
By default, root user privileges are required to discover SAN resources in UNIX environments. Typically, this escalation is done by setting the file access permissions using the setuid (set-user-ID mode bit) term or by using the sudo command.

Model objects with associated attributes


The Host storage sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about storage resources in your IT environment. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. dev.DiskDrive v AnsiT10Id v Name v Type dev.DiskPartition v BlockSize v Name v NumOfBlocks dev.FCPort v DeviceID v PermanentAddress v PortType

270

Application Dependency Discovery Manager: Sensors

v Speed dev.FCVolume v BlockSize v Controller v DeviceID v FCPLun v Name v NodeWWN v NumOfBlocks v v v v v PortWWN SCSIBus SCSILun SCSITarget Type

dev.SCSIProtocolController v EndPoints v FCPorts v Name dev.SCSIProtocolEndPoint v Name v WorldWideName dev.SCSIVolume v BasedOn v BlockSize v DeviceID v v v v v v v Name NumOfBlocks SCSIBus SCSILun SCSITarget Type RealizedBy

dev.StorageVolume v BasedOn v v v v v v BlockSize DeviceID Name NumOfBlocks RealizedBy Type

storage.HostBusAdaptor v Name v SCSIProtocolControllers v WorldWideName


Chapter 7. Storage sensors

271

Configuring the sensor


Before running a discovery, you must configure the sensor.

Copying the collection engine file to a location accessible to the target host system
The Host storage sensor uses an executable program, the collection engine file to discover storage data. By default, the Host storage sensor copies the collection engine 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 to run the collection engine program. Copying an application to a host system that requires root privileges can introduce a security risk. To avoid this risk, the sensor supports a configuration that allows the collection engine to be deployed to, and accessed from, a secure location. To run the collection engine from a secure location, copy the collection engine file to 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-engine directory on the TADDM server, copy the file to a location that is accessible to the 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 the host system, and type the location of the collection engine directory. v For all other systems, edit the com.collation.discover.agent.path in the collation.properties file on the TADDM server, and type the location of the collection engine directory. Specify the location of the collection engine directory for the appropriate target operating system. v Modify the discovery profile for the Host storage sensor on the TADDM server. Type the path to the collection engine directory in the CollectionEnginePath or the CollectionEngineWindowsPath attribute or both, if required. 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 the discovery can require privilege escalation. Typically, this escalation is done by setting the file access permissions using the setuid (set-user-ID mode bit) term or by using the sudo command. For Windows operating systems, the discovery user must be a member of the Administrators group.

Configuring the discovery profile


The Host storage sensor, is not enabled by default. To enable the sensor, you must create 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 HBAs and 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 the host system.

272

Application Dependency Discovery Manager: Sensors

The following attributes can be modified: deployCollectionEngine The default value for the deployCollectionEngine attribute is true. The sensor copies the collection engine file to a location on the target host system. After the discovery is complete the collection engine file is deleted from the host. The location is entered in the collectionEnginePath or the collectionEngineWindowsPath attribute. If no path is specified on Windows systems, the collection engine file is copied to the TEMP directory. For all other systems, the collection engine file is copied to the home directory of the user (running the discovery) on the target host system. If the value is false the collection engine file is not copied. collectionEnginePath There is no default value for the collectionEnginePath attribute. Enter the absolute path to the UNIX collection engine directory, if required. collectionEngineWindowsPath There is no default value for the collectionEngineWindowsPath attribute. Enter the absolute path to the Windows collection engine directory, if required. Entering the Windows path when the directory resides on a network drive (created using the net use command), might not work. Instead, enter the Windows path using the UNC (Universal Naming Convention) method. For example, \\hostname\share\CollectionEngine. collectionEngineSudoCommand There is no default value for the collectionEngineSudoCommand attribute. Enter the command to use for privilege escalation on UNIX systems. collectionEngineTimeout The default value for the collectionEngineTimeout attribute is 30. This value specifies the time interval in minutes before a timeout occurs during a discovery. collectionEngineForceUniqueName The default value for the collectionEngineForceUniqueName attribute is false. If the value is false, the collection engine is not renamed when the collection engine is copied to the target system. If the value is true, a time stamp is added to the name of the collection engine before it is copied to the target system. If you want to use sudo to give the discovery user permission to run the collection engine, then the collection engine name cannot be changed. In this case, the default value of false must be used. In environments that use concurrent discovery, if multiple discoveries are performed at the same time, against the same target systems, collisions can occur when deploying the collection engine. In situations like this, the collectionEngineForceUniqueName attribute can be set to true to force the name of the collection engine to be unique on the target system. If this attribute is set to true, sudo cannot be used. If the Host storage sensor is enabled, do not enable the Storage sensor. If both sensors are enabled, some of the storages resources are discovered twice.

Configuring the access list


This topic describes the access details that you require, depending on your configuration.
Chapter 7. Storage sensors

273

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 authentication to the target computer system. Typically, an account with non-root privilege can be used. The commands that are used by the Host storage sensor carrying out the discovery can require privilege escalation. Typically, this escalation is done by setting the file access permissions using the setuid (set-user-ID mode bit) term or by using the sudo command.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. The sensor uses the following entries, which explicitly specify the location of the collection 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 IP address or a scope set name to the property, for example com.collation.discover.agent.path.Linux.1.2.3.4. If the collection engine exits on multiple target computers that have the same operating system, but the collection engines reside in different paths, enter the paths in the collation.properties file. Separate each unique path with a colon.

Troubleshooting the sensor


This topic describes common problems that occur with the Host storage sensor and presents solutions for those problems.

Commands fail because of insufficient privileges


Problem Command failures occurred due to permissions denied errors and are recorded in the log files. Solution Verify that the commands that require privilege escalation are configured correctly.

Dscovery takes a long time to run


Problem The discovery takes a long time to run. Solution Check if the StorageSensor sensor is enabled and disable it. If both sensors are enabled, some of the storages resources are discovered twice.

274

Application Dependency Discovery Manager: Sensors

Host storage data is not discovered


Problem Host storage data is not discovered. Solution Verify that the vendor's host bus adapter (HBA) API library files are installed and configured correctly on the host system. Missing library files might be identified in the HostStorageSensor log file.

WWPN and WWNN information are not displayed


Problem The worldwide port name (WWPN) and worldwide node name (WWNN) for an FC volume are not displayed. Solution TADDM uses the HBA API for FC volume discovery. The HBA API provides, a mapping from the OS identification of a SCSI volume to the FC representation of the volume. The FC representation includes the WWPN of the port from the HBA that finds the volume. On multiport HBAs, there is no way to determine which port a SCSI volume applies to. This limitation is in the HBA API. The HBA API specification has been updated to address this issue, but the change might not be implemented in all HBA API libraries. Ensure that the latest version of the HBA vendor's HBA API library is installed on the target host system. In summary, if the HBA API is unable to provide the mapping of a SCSI volume to its FC representation, then the WWPN and WWNN cannot be determined.

Expected number of HBAs are not displayed


Problem TADDM does not display the expected number of HBAs. Solution TADDM uses the HBA API for HBA discovery. For each adapter that the HBA API returns, TADDM creates an HBA model object. The adapters WWNN is used by TADDM to name the HBA. The number of adapters might not match the number of physical HBA cards that are installed in the host computer system, or the number of WWNNs returned by the basic system commands. How the HBA API library interprets adapters and WWNNs are determined by the HBA vendor's, HBA API library implementation. For example, some vendors might represent a multiport HBA card using one adapter with one WWNN. Other vendors can represent a multiport HBA card using one adapter per port, with each adapter having its own unique WWNN.

Port type and port speed are not displayed


Problem The port type and port speed for an FC port are not displayed. Solution TADDM uses the HBA API for FC Port discovery. However, some HBA API libraries might not support these attributes, or the HBA vendor's HBA API library might need to be updated. Ensure that the latest version of the HBA API library is installed on the target host system. If the HBA API library cannot determine the port type and port speed, then these attributes are not displayed.
Chapter 7. Storage sensors

275

SCSI bus, SCSI target and SCSI LUN are not displayed correctly
Problem The SCSI bus, SCSI target, and SCSI LUN for an FC volume are not displayed or the correct values are not displayed. Solution TADDM uses the HBA API to discover SCSI information about an FC volume. However, some HBA API libraries might not support these attributes, or might not return the correct values for these attributes. To resolve this problem, the HBA vendor's HBA API library might need to be updated. Ensure that the latest version of the HBA API library is installed on the target host system. If the HBA API library cannot determine the SCSI information, then these attributes are not displayed or might display incorrect values.

FC volume information is not displayed correctly


Problem The FC volume information is not displayed or does not display correct values. Solution TADDM uses the HBA API to discover information about an FC volume. However, if there is a problem with the HBA API library, TADDM might display incorrect values for some FC volume attributes. For example, block size. To resolve this problem, ensure that the latest version of the HBA API library is installed on the target host system and configured correctly. If the HBA API library is not configured correctly, FC volume attributes might not display or might display incorrect values.

IBM Tivoli Storage Productivity Center sensor


The IBM Tivoli Storage Productivity Center sensor discovers storage resources that are 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 arrays v Switches v Hosts v Fabrics v Zones v v v v v Storage volumes Array and switch ports File systems Disk partitions NAS-related data

Some of these resources can also be discovered by the host storage sensor (for example, data that is related to hosts) and the Fibre Channel switch sensor (for example, data that is related to switches).

276

Application Dependency Discovery Manager: Sensors

Sensor name that is used in the GUI and logs


TPCStorageSensor

Model objects with associated attributes


The IBM Tivoli Storage Productivity Center sensor creates model objects with associated attributes. The attributes indicate the type of information that the sensor collects about storage resources that are stored in Tivoli Storage Productivity Center database. The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. dev.BasedOnExtent v Source v Target v Type dev.Controller v Name v Parent dev.DiskDrive v DiskSize v Model v Name v Parent v SerialNumber v Type v Vendor dev.DiskPartition v Capacity v Name v Parent v PartitionType v RealizedBy dev.FCPort v Label v Parent v PermanentAddress v PortNumber v PortType v Speed dev.FCVolume v Capacity v FCPLun v Name v Parent
Chapter 7. Storage sensors

277

v v v v

Type PortWWN HostPaths BasedOn

dev.RealizesExtent v Source v Target v Type dev.SCSIPath v ArrayVolume v HostEndPoint v LUN v Parent v Volume dev.SCSIProtocolEndPoint v WorldWideName dev.TapeDrive v Label v Type v WorldWideName net.IpAddress v DotNotation v StringNotation net.IpInterface v IpAddress v Parent relation.ConnectedTo v Source v Target v Type storage.Fabric v v v v v v Fcswitch Label Name SourceToken Virtual ZoneSets

v Zones storage.FCSwitch v FCPorts v FCSwitchStatus v Fcport v ManagementURL

278

Application Dependency Discovery Manager: Sensors

v v v v v

Manufacturer Model Name ROMVersion SerialNumber

v Type v WorldWideName v IpInterfaces storage.StoragePool v v v v v v AnsiT10Id Capacity Label Members Raid Level RemainingManagedSpace

v StorageSubSystem v TotalAvailableSpace v TotalManagedSpace storage.StorageSubSystem v AllocatedCapacity v AnsiT10Id v v v v v v v v v v v v v v v v v v AvailabilityState AvailableCapacity CacheSize FCPorts Fqdn IpInterfaces IsNetworkAttached Manufacturer Members MemorySize Model NumCPUs ROMVersion SerialNumber StoragePools Type VolumeGroupCapacity VolumeGroupFreeSpace

storage.StorageVolume v BlockSize v Capacity v FreeSpace v Name


Chapter 7. Storage sensors

279

v v v v v

Parent RealizedBy RedundancyMethod SourceToken Type

v Virtual v Paths storage.TapeLibrary v AnsiT10Id v v v v v v Description Devices Manufacturer Model ROMVersion SerialNumber

v TapeMediaChangers v Type storage.TapeMediaChanger v Caption v Description v Fqdn v v v v Label ROMVersion Type WorldWideName

storage.Zone v Active v Description v Name v Parent storage.ZoneSet v Active v Label v Name v Parent v Zones Multiple operating systems: sys.aix.Aix sys.hpux.HpUx sys.linux.Linux sys.netware.Netware sys.OperatingSystem sys.sun.Solaris sys.vmware.VmwareESX

280

Application Dependency Discovery Manager: Sensors

sys.windows.WindowsOperatingSystem The following attributes are associated with these model objects: v FQDN v OSConfidence v OSName v OSVersion v Parent v SoftwareComponents v SystemGuid Multiple Computer Environments: sys.aix.AixUnitaryComputerSystem sys.ComputerSystem sys.hpux.HpUxUnitaryComputerSystem sys.linux.LinuxUnitaryComputerSystem sys.sun.SunSPARCUnitaryComputerSystem sys.vmware.VmwareUnitaryComputerSystem sys.windows.WindowsComputerSystem The following attributes are associated with these model objects: v CPUSpeed v CPUType v Devices v FCPorts v FileSystems v v v v v v v v v v v v v Fqdn IpInterfaces Manufacturer MemorySize Model NumCPUs OSInstalled OSRunning SerialNumber Signature Type Name UUID

v MacAddress v VMID sys.FileSystemExport v Name v Parent sys.FileSystemService v Exports v Host


Chapter 7. Storage sensors

281

v Name sys.NFSExport v Name v Parent sys.NFSService v Exports v Host v Name Multiple file systems: sys.LocalFileSystem sys.sun.SolarisFileSystem sys.unix.UnixFileSystem sys.windows.WindowsFileSystem The following attributes are associated with these model objects: v AvailableInodes v v v v v AvailableSpace Capacity MountPoint Parent StorageExtent

v TotalInodes v Type sys.SMBExport v Name v Parent v Path v Type sys.SMBService v Exports v Host v Name sys.SoftwareComponent v Name v Parent v SoftwareVersion

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the Tivoli Storage Productivity Center properties file


The Tivoli Storage Productivity Center sensor uses SQL queries to extract data from the Tivoli Storage Productivity Center database. The SQL queries are defined in the tpc.config file and the execution of these queries is controlled by the properties defined in tpc.properties file.

282

Application Dependency Discovery Manager: Sensors

The tpc.config and the tpc.properties are located in: COLLATION_HOME/osgi/ plugins/com.ibm.cdb.discover.sensor.app.srm.tpc_7.2.0. The sensor uses the following entries in the tpc.properties file to determine which queries to run: com.ibm.cdb.discover.sensor.app.srm.tpc.ArrayQueries This property is related to array resources. By default, the following queries are enabled: ARRAY, ARRAY_SUM_SOURCE, ARRAY_VOLUME_GROUP, ARRAY_DRIVE, ARRAY_PORT, ARRAY_VOLUME. com.ibm.cdb.discover.sensor.app.srm.tpc.HostQueries This property is related to host resources. By default, the following queries are 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. The HOST_SCSI_PATH query is used to create the end-to-end storage mapping from Fibre Channel volumes on a host to the volumes on a storage array. This query is enabled by default. Depending on how large the storage environment is, running this query can increase the discovery time of the sensor significantly. Hence, when discovering large storage environments, it is better to enable the HOST_SCSI_PATH query only occasionally. To disable this query, do not include the HOST_SCSI_PATH in the property: com.ibm.cdb.discover.sensor.app.srm.tpc.HostQueries. The following example shows the com.ibm.cdb.discover.sensor.app.srm.tpc.HostQueries property with the HOST_SCSI_PATH query disabled: com.ibm.cdb.discover.sensor.app.srm.tpc.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.sensor.app.srm.tpc.FabricQueries This property is related to fabric resources. By default, the following queries are enabled: FABRIC, ZONE_SET, ZONE. com.ibm.cdb.discover.sensor.app.srm.tpc.SwitchQueries This property is related to switch resources. By default, the following queries are enabled: SWITCH, SWITCH_PORT. com.ibm.cdb.discover.sensor.app.srm.tpc.NASQueries This property is related to NAS resources. By default, the following queries are enabled: NAS_FILER, NAS_CONTROLLER, NAS_VOLUME, NAS_FS, NAS_DEVICE, NAS_FS_EXPORT. com.ibm.cdb.discover.sensor.app.srm.tpc.TapeQueries This property is related to TAPE resources. By default, the following queries are enabled: TAPE_LIBRARY, TAPE_MEDIA_CHANGER, TAPE_DRIVE. com.ibm.cdb.discover.sensor.app.srm.tpc.SummaryQueries This property is related to SUMMARY resources. By default, the following query is enabled: PORT_CONNECTIVITY. The following properties are used to control the discovery of certain types of computer systems by the IBM Tivoli Storage Productivity Center sensor: com.ibm.cdb.discover.sensor.app.srm.tpc.ignoreAixCompSys=true This property determines whether the IBM Tivoli Storage Productivity Center sensor discovers computer systems on AIX operating systems or

Chapter 7. Storage sensors

283

not. By default, it is set to true which means that the sensor does not discover computer systems on AIX operating systems. com.ibm.cdb.discover.sensor.app.srm.tpc.IgnoreCSWithoutMacaddr=true This property determines whether the IBM Tivoli Storage Productivity Center sensor discovers computer systems without a MAC address. By default, it is set to true which means that the sensor does not discover computer systems without a MAC address.

Configuring the discovery profile


The TPCStorageSensor is enabled by default in the discovery profile. Create a new profile to modify the following attributes: discoverHosts The 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 file system services. If the value is false, host-related data is not discovered by the sensor. discoverSwitch The default value for the discoverSwitch attribute is true. The sensor discovers switch related data, for example, switch, switch ports, and FC ports. If the value is false, switch related data is not discovered by the sensor. restrictByScope The default value for the restrictByScope attribute is false. The sensor discovers all the hosts that the Tivoli Storage Productivity Center server has already discovered. If the value is true, the sensor discovers the hosts within the discovery scope range of the sensor. The Host storage sensor and the Fibre Channel switch sensor also discover data related to hosts and switches. When discoverHosts and discoverSwitch are enabled, consider disabling the Host storage sensor and the Fibre Channel switch sensor to prevent resources being discovered twice.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 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 sensor


This topic describes common problems that occur with the IBM Tivoli Storage Productivity Center sensor and presents solutions for those problems.

284

Application Dependency Discovery Manager: Sensors

Problems connecting to the Tivoli Storage Productivity Center database cause sensor failure
Problem The sensor fails due to problems connecting to the Tivoli Storage Productivity Center database. Solution Verify that the DB2 credentials of the Tivoli Storage Productivity Center database have been entered.

Host computers are not discovered


Problem Host computers are not discovered. Solution The sensor only discovers host systems that are managed by the Tivoli Storage Productivity Center agent. In addition, verify that the attribute discoverHosts is true for the sensor.

Discovery takes a long time to run


Problem The discovery takes a long time to run. Solution If the attribute discoverHosts is true, check if the HostStorageSensor sensor is enabled and disable it. If both sensors are enabled, some of the storages resources are discovered twice. If the attribute discoverSwitch is true, check if the FCSwitchSensor sensor is enabled and disable it. If both sensors are enabled, some of the storages resources 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 can generate large volumes of data are: ARRAY_VOLUME, HOST_SCSI_PATH, and SWITCH_PORT. By default, these queries are disabled.

Computer systems are not reconciled


Problem Computer systems discovered by the TPCStorageSensor do not reconcile with the same computer systems discovered by the computer system sensors. Solution Computer systems in a storage environment can be physically partitioned or virtualized. If these systems are discovered by the TPCStorageSensor, and also by a computer system sensor, the two sets of discovered resources are not reconciled with each other. For example: v Logical partitions (LPARs) on pSystems discovered by TPCStorageSensor and AixComputerSystemSensor v Virtual I/O Server (VIOS) discovered by TPCStorageSensor and HMC sensor v Node partitions (NPARs) on HP systems discovered by TPCStorageSensor and HpUxComputerSystemSensor

Chapter 7. Storage sensors

285

v Zones on Solaris systems discovered by TPCStorageSensor and SunSparcComputerSystemSensor To ensure that there is no duplication of computer systems, in the TADDM UI you must select the duplicate computer systems and merge them manually.

Out-of-memory error when HOST_SCSI_PATH query is enabled


Problem Depending on the storage environment, the HOST_SCSI_PATH query can return a large result set which might lead to an out-of-memory error. Solution The sensor caps the number of rows it processes for the HOST_SCSI_PATH query to a default value of 20,000 in order to prevent 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-memory messages, when the HOST_SCSI_PATH query is enabled by using one of the following methods: Modify the default number of rows processed by the sensor Edit the COLLATION_HOME/osgi/plugins/ com.ibm.cdb.discover.sensor.app.srm.tpc_7.2.0/tpc.properties file and add the following property:
com.ibm.cdb.discover.sensor.app.srm.tpc.HOST_SCSI_PATH.maxrows= X

where X is the maximum number of rows the sensor processes for this 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 the com.collation.Discover.jvmargs.ibm property. For example, to set the heap size to 1824 MB, add the following line:
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 the following property, where value is the number of milliseconds allowed for the sensor to run:
com.collation.discover.agent.TPCStorageSensor.timeout=value

If you do not specify a value, the default value of 600000 is used. v Restart TADDM. Restrict the scope of storage arrays and Computer systems discovered The number of rows returned by the HOST_SCSI_PATH query can be reduced by restricting the scope 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 Storage Productivity Center server to be discovered. Include the IP

286

Application Dependency Discovery Manager: Sensors

address, Range, or Subnet information of the arrays and computers system to be discovered. The IP address of the storage arrays and IP address of the computer system must be in the same scope set as the Tivoli Storage Productivity Center server for the discovery. These values enable the SCSI path data to be included in the results of the discovery. 2. From the Discovery Management Console, click the Discovery Profiles 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 3 Discovery , 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 Configuration window, to restrict the scope of discovery, click restrictByScope. Then double-click the Value field in the row, and type true. 8. Click OK to return to the Discovery Profiles window. 9. In the Discovery Profiles window, click Save. 10. Start a discovery using the new profile. After a discovery using the sensor, review the $COLLATION_HOME/log/sensors/runId/TPCStorageSensor-IPPORT.log(.N) to see the number of SCSI paths that exist per storage array IP address and per host IP address. The following text 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 paths ip#2/4 with ipAddress 10.3.41.289 has 527 valid scsi paths ip#3/4 with ipAddress 10.3.43.19 has 108 valid scsi paths ip#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 paths ip#2/2 with ipAddress 10.0.17.2 has 736 valid scsi paths

Run a discovery with the Tivoli Storage Productivity Center server in a scope of its own To get the complete result set of the HOST_SCSI_PATH query 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.

Chapter 7. Storage sensors

287

Storage sensor
The storage sensor discovers the storage that is attached to a computer system. The following resources are examples of what the sensor discovers: v v v v v Disks Partitions Logical volumes Physical volumes File systems

Sensor name that is used in the GUI and logs


StorageSensor

Limitations
Access to the /dev/dsk directory is not available on Solaris local or branded zone target systems. Therefore, not all storage information is retrieved.

Model objects created


The sensor creates the following model objects: v dev.BasedOnExtent v dev.ControlledBy v dev.Controller v dev.DiskDrive v dev.DiskPartition v v v v v dev.FCVolume dev.RealizesExtent dev.SCSIVolume dev.StorageExtent dev.StorageVolume

v sys.NFSFileSystem v sys.unix.UnixFileSystem v sys.LocalFileSystem

Configuring the sensor


Before running a discovery, you must configure the sensor.

Configuring the access list


This topic describes the access details that you require, depending on your configuration. 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 authentication to the target computer system.

288

Application Dependency Discovery Manager: Sensors

Typically, an account with non-root privilege can be used. However, some commands that TADDM uses during the discovery process can require privilege escalation (typically done using the sudo command). For more information, see the topic Commands that might require elevated privilege in the Administering topics in the TADDM information center.

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. The following TADDM server properties specify operating system commands that TADDM uses to retrieve storage information: v com.collation.platform.os.command.lvm.lvdisplay v com.collation.platform.os.command.lvm.vgdisplay v com.collation.platform.os.command.lvm.pvdisplay v com.collation.platform.os.command.lputil.SunOS These commands require elevated privilege to run on the target system, and they must be configured to use the sudo command. For more information, see the topic Commands that might require elevated privilege in the Administering topics in the TADDM information center.

Troubleshooting the sensor


This topic describes common problems that occur with the Storage sensor and presents solutions for those problems.

General problems
Determine whether information is missing, and identify any command failures due to permissions denied errors. Verify that commands that require privilege escalation are properly configured. See Configuring the collation.properties file entries for details.

Veritas Storage Foundation sensor


The Veritas Storage Foundation sensor discovers Veritas Storage Foundation systems. The Veritas Storage Foundation sensor combines the following principal components and provides a solution for online storage management: v VERITAS Volume Manager v VERITAS File System Physical disks are grouped into logical volumes to improve disk utilization and reduce wasted space. VERITAS Volume Manager allows administrators to work with logical names (volumes) rather than through direct access to physical devices. The VERITAS File System also provides an enterprise journaling file system increasing performance and reliability. The Veritas Storage Foundation sensor is responsible for discovering the following general Volume Manager configurations: v Version
Chapter 7. Storage sensors

289

v Installation directory v 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 system and the disk layout version is collected.

Sensor name that is used in the GUI and logs


VeritasStorageSensor

Security issues
The default user to discover Computer System is used.

Limitations
The licenses are not supported. There are no application descriptors.

Model objects created


The sensor creates the following model objects: v app.ConfigFile v v v v v app.SoftwareInstallation dev.MediaAccessDevice dev.veritas.VeritasDiskGroup dev.veritas.VeritasPlex dev.veritas.VeritasSubdisk

v dev.veritas.VeritasVMDisk v dev.veritas.VeritasVolume v sys.LocalFileSystem v sys.veritasVeritasStorageService

Configuring the collation.properties file entries


This topic lists the collation.properties file entries that the sensor uses. The following properties may require elevated privilege. v com.collation.discover.agent.command.vxdisk=vxdisk v v v v com.collation.discover.agent.command.vxdg=vxdg com.collation.discover.agent.command.vxprint=vxprint com.collation.discover.agent.command.vxupgrade=vxupgrade com.collation.discover.agent.command.vxdf=df

Troubleshooting the sensor


This topic describes common problems that occur with the Veritas Storage Foundation sensor and presents solutions for those problems.

290

Application Dependency Discovery Manager: Sensors

The sensor fails with a timeout error on a Windows platform


Problem The Veritas Storage Foundation sensor fails with a timeout error on a Windows platform Solution In the configuration file, change the liteDiscoveryMode to true if the sensor times out on a Windows platform. The following example shows the attributes within a predefined configuration file:
<results xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <VeritasStorageAgentConfiguration xsi: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>

Chapter 7. Storage sensors

291

292

Application Dependency Discovery Manager: Sensors

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 in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, 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 be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

Copyright IBM Corp. 2008, 2012

293

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, 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 material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. If you are viewing this information in softcopy form, the photographs and color illustrations might not be displayed.

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International 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 and trademark information at http://www.ibm.com/legal/copytrade.shtml.

294

Application Dependency Discovery Manager: Sensors

Itanium is a trademark or registered trademark of Intel Corporation or its subsidiaries in the United States and other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others.

Notices

295

296

Application Dependency Discovery Manager: Sensors

Printed in USA

You might also like