Cmdb Sensor PDF

Tivoli Application Dependency Discovery ManagerVersion 7 Release 2.1

Sensor Reference for Fix Pack 3

��

NoteBefore 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 DiscoveryManager (product number 5724-N55) and to all subsequent releases and modifications until otherwise indicated innew editions.

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

Contents

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

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

About this information . . . . . . . . xi

Chapter 1. Overview . . . . . . . . . 1Sensors that are enabled by default . . . . . . . 1

Level 1 discovery profile . . . . . . . . . 1Level 2 discovery profile . . . . . . . . . 2Level 3 discovery profile . . . . . . . . . 3Utilization discovery profile . . . . . . . . 6

Sensors that support asynchronous or script-baseddiscovery . . . . . . . . . . . . . . . 7Sensors that support discovery using IBM TivoliMonitoring . . . . . . . . . . . . . . . 7Sensor setup problems . . . . . . . . . . . 9

Chapter 2. Application sensors . . . . 11Active Directory sensor . . . . . . . . . . 11

Model objects with associated attributes . . . . 11Configuring the sensor . . . . . . . . . 12

Apache sensor . . . . . . . . . . . . . 12Asynchronous and script-based discoverysupport. . . . . . . . . . . . . . . 13Configuring the sensor . . . . . . . . . 14Troubleshooting the sensor . . . . . . . . 14

Citrix server sensor . . . . . . . . . . . . 15Troubleshooting the sensor . . . . . . . . 16

DNS sensor . . . . . . . . . . . . . . 16Troubleshooting the sensor . . . . . . . . 16

HIS sensor. . . . . . . . . . . . . . . 16Model objects with associated attributes . . . . 17Configuring the access list . . . . . . . . 21Troubleshooting the sensor . . . . . . . . 21

IBM Cluster Systems Management sensor . . . . 21Configuring the sensor . . . . . . . . . 21

IBM High-Availability Cluster Multi-Processingsensor . . . . . . . . . . . . . . . . 24

Model objects with associated attributes . . . . 24Configuring the sensor . . . . . . . . . 26Troubleshooting the sensor . . . . . . . . 27

IBM Lotus Domino server sensor . . . . . . . 27Asynchronous and script-based discoverysupport. . . . . . . . . . . . . . . 29Configuring the access list . . . . . . . . 30Troubleshooting the sensor . . . . . . . . 30

IBM Tivoli Monitoring Scope sensor . . . . . . 31Model objects with associated attributes . . . . 32Configuring the sensor . . . . . . . . . 32Uninstalling the sensor . . . . . . . . . 38Troubleshooting the sensor . . . . . . . . 39

IBM WebSphere sensor . . . . . . . . . . 45

Asynchronous and script-based discoverysupport. . . . . . . . . . . . . . . 47Configuring the sensor . . . . . . . . . 48Using the WebSphere seed sensor for z/OS. . . 54Troubleshooting the sensor . . . . . . . . 58

IBM WebSphere eXtreme Scale cache sensor . . . 64Model objects with associated attributes . . . . 65Configuring the sensor . . . . . . . . . 65

IBM WebSphere Message Broker sensor . . . . . 65Configuring the sensor . . . . . . . . . 66Troubleshooting the sensor . . . . . . . . 67

IBM WebSphere MQ Server sensor . . . . . . 67Asynchronous and script-based discoverysupport. . . . . . . . . . . . . . . 68Configuring the sensor . . . . . . . . . 69Troubleshooting the sensor . . . . . . . . 71

iPlanet server sensor . . . . . . . . . . . 71JBoss server sensor . . . . . . . . . . . . 71

Configuring the access list . . . . . . . . 72Troubleshooting the sensor . . . . . . . . 72

LDAP sensor . . . . . . . . . . . . . . 73Configuring the access list . . . . . . . . 73Troubleshooting the sensor . . . . . . . . 73

Microsoft Cluster sensor . . . . . . . . . . 74Model objects with associated attributes . . . . 74Configuring the access list . . . . . . . . 76Troubleshooting the sensor . . . . . . . . 76

Microsoft Exchange Server sensor . . . . . . . 77Configuring the sensor . . . . . . . . . 77Troubleshooting the sensor . . . . . . . . 78

Microsoft Exchange 2007 Server sensor . . . . . 81Model objects with associated attributes . . . . 81Configuring the sensor . . . . . . . . . 86Troubleshooting the sensor . . . . . . . . 86

Microsoft HyperV sensor . . . . . . . . . . 87Model objects with associated attributes . . . . 88Configuring the sensor . . . . . . . . . 88Troubleshooting the sensor . . . . . . . . 89

Microsoft IIS Web server sensor . . . . . . . 89Configuring the access list . . . . . . . . 90Troubleshooting the sensor . . . . . . . . 90

NFS sensor . . . . . . . . . . . . . . 91Oracle Application Server sensor . . . . . . . 91

Configuring the sensor . . . . . . . . . 93Troubleshooting the sensor . . . . . . . . 94

SAP CCMS server sensor . . . . . . . . . . 96Configuring the sensor . . . . . . . . . 96Troubleshooting the sensor . . . . . . . . 98

SAP SLD server sensor . . . . . . . . . . 99Configuring the sensor . . . . . . . . . 100Troubleshooting the sensor . . . . . . . . 101

SMB server sensor. . . . . . . . . . . . 101Troubleshooting the sensor . . . . . . . . 101

SMS server sensor . . . . . . . . . . . . 102Configuring the collation.properties file entries 102

SysImager sensor . . . . . . . . . . . . 103

© Copyright IBM Corp. 2008, 2012 iii

Configuring the sensor . . . . . . . . . 103Veritas cluster sensor . . . . . . . . . . . 105


VMware Virtual Center server sensor . . . . . 107Model objects with associated attributes . . . 108Configuring the sensor . . . . . . . . . 112Troubleshooting the sensor . . . . . . . . 113

WebLogic sensor . . . . . . . . . . . . 114Configuring the sensor . . . . . . . . . 116Troubleshooting the sensor . . . . . . . . 120

WebLogic SSH sensor . . . . . . . . . . 123Resources that the sensor discovers . . . . . 125Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 127Configuring the sensor . . . . . . . . . 127Troubleshooting the sensor . . . . . . . . 129

Chapter 3. Database sensors. . . . . 131IBM DB2 sensor . . . . . . . . . . . . 131

Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 132Configuring the sensor . . . . . . . . . 132Troubleshooting the sensor . . . . . . . . 134

IBM Informix sensor . . . . . . . . . . . 136Model objects with associated attributes . . . 136Configuring the access list . . . . . . . . 137Troubleshooting the sensor . . . . . . . . 138

Microsoft SQL Server sensor . . . . . . . . 138Configuring the sensor . . . . . . . . . 139Troubleshooting the sensor . . . . . . . . 141

Oracle sensor . . . . . . . . . . . . . 142Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 142Model objects with associated attributes . . . 143Configuring the sensor . . . . . . . . . 146Troubleshooting the sensor . . . . . . . . 147

Sybase sensor . . . . . . . . . . . . . 147Model objects with associated attributes . . . 148Configuring the access list . . . . . . . . 152

Sybase IQ sensor . . . . . . . . . . . . 152Configuring the access list . . . . . . . . 153

Chapter 4. Generic sensors . . . . . 155Anchor sensor . . . . . . . . . . . . . 155

Configuring the sensor . . . . . . . . . 155Asynchronous discovery sensor . . . . . . . 156Asynchronous discovery ping sensor . . . . . 157Custom application server sensor. . . . . . . 157Custom MIB2 computer system sensor . . . . . 158Generic computer system sensor . . . . . . . 158Generic server sensor. . . . . . . . . . . 159

Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 159Configuring the collation.properties file entries 160

IBM Tivoli Utilization sensor . . . . . . . . 160Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 161Model objects with associated attributes . . . 162Configuring the sensor . . . . . . . . . 163

Troubleshooting the sensor . . . . . . . . 167IP device sensor . . . . . . . . . . . . 167IP interface sensor . . . . . . . . . . . . 168Ping sensor . . . . . . . . . . . . . . 168

Configuring the collation.properties file entries 168Troubleshooting the sensor . . . . . . . . 169

Port sensor . . . . . . . . . . . . . . 169Session sensor . . . . . . . . . . . . . 170Stack Scan sensor . . . . . . . . . . . . 170


Chapter 5. Network sensors . . . . . 179Overview of SNMP sensors . . . . . . . . 179

Calling sequence for SNMP sensors . . . . . 179SNMP MIB walking and debugging SNMPsensors . . . . . . . . . . . . . . 180Maintaining SNMP computer system templatesand configuration files . . . . . . . . . 181

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

Alteon SNMP sensor . . . . . . . . . . . 185Configuring the access list . . . . . . . . 186

Alteon VLAN sensor . . . . . . . . . . . 186Configuring the access list . . . . . . . . 187

BIG-IP port sensor. . . . . . . . . . . . 187Configuring the access list . . . . . . . . 187

BIG-IP SNMP sensor . . . . . . . . . . . 188Configuring the access list . . . . . . . . 189

BIG-IP VLAN sensor . . . . . . . . . . . 189Configuring the access list . . . . . . . . 190

Bridge SNMP sensor . . . . . . . . . . . 190Configuring the access list . . . . . . . . 192

Bridge SNMP 2 sensor . . . . . . . . . . 192Configuring the access list . . . . . . . . 193

Check Point sensor . . . . . . . . . . . 193Configuring the collation.properties file entries 194Troubleshooting the sensor . . . . . . . . 194

Check Point SNMP sensor . . . . . . . . . 194Configuring the access list . . . . . . . . 195

Cisco Adaptive Security Appliance sensor . . . . 195Configuring the sensor . . . . . . . . . 196

Cisco Discovery Protocol sensor . . . . . . . 196Configuring the access list . . . . . . . . 197Troubleshooting the sensor . . . . . . . . 197

Cisco IOS sensor . . . . . . . . . . . . 198Configuring the sensor . . . . . . . . . 198

Cisco port sensor . . . . . . . . . . . . 199Configuring the access list . . . . . . . . 199

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

CiscoWorks sensor . . . . . . . . . . . 201Model objects with associated attributes . . . 201Configuring the access list . . . . . . . . 202

Entity MIB sensor . . . . . . . . . . . . 202Configuring the access list . . . . . . . . 203

Extreme VLAN sensor . . . . . . . . . . 203Configuring the access list . . . . . . . . 204

IBM BladeCenter SNMP sensor . . . . . . . 204Configuring the sensor . . . . . . . . . 206Troubleshooting the sensor . . . . . . . . 207

iv Application Dependency Discovery Manager: Sensors

LAN Manager SNMP sensor . . . . . . . . 207Configuring the access list . . . . . . . . 207

NetFlow sensor. . . . . . . . . . . . . 208Configuring the sensor . . . . . . . . . 209

NetScreen SNMP sensor . . . . . . . . . . 211Configuring the access list . . . . . . . . 212

Nokia SNMP sensor . . . . . . . . . . . 212Configuring the access list . . . . . . . . 213

PIX sensor . . . . . . . . . . . . . . 213Configuring the access list . . . . . . . . 214Configuring the collation.properties file entries 214

SNMP Light sensor . . . . . . . . . . . 215Configuring the access list . . . . . . . . 215

SNMP MIB2 sensor . . . . . . . . . . . 216Configuring the access list . . . . . . . . 218Troubleshooting the sensor . . . . . . . . 219

Chapter 6. Operating system sensors 221HP NonStop computer system sensor . . . . . 221

Asynchronous discovery support . . . . . . 221Troubleshooting the sensor . . . . . . . . 222

HP-UX computer system sensor . . . . . . . 222Configuring the sensor . . . . . . . . . 223Troubleshooting the sensor . . . . . . . . 224

IBM AIX computer system sensor . . . . . . 225Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 226Model objects with associated attributes . . . 226Configuring the sensor . . . . . . . . . 229Troubleshooting the sensor . . . . . . . . 230

IBM Hardware Management Console sensor . . . 230Model objects with associated attributes . . . 231Configuring the sensor . . . . . . . . . 235

IBM Integrated Virtualization Manager sensor . . 236Configuring the sensor . . . . . . . . . 236

IBM i computer system sensor. . . . . . . . 237Configuring the access list . . . . . . . . 238

IPSO computer system sensor . . . . . . . . 238Configuring the access list . . . . . . . . 239

Linux computer system sensor . . . . . . . 239Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 240Configuring the sensor . . . . . . . . . 241Troubleshooting the sensor . . . . . . . . 242

OpenVMS computer system sensor . . . . . . 243Configuring the access list . . . . . . . . 243

Solaris computer system sensor . . . . . . . 243Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 245Configuring the sensor . . . . . . . . . 246Troubleshooting the sensor . . . . . . . . 247

Solaris zones generic sensor . . . . . . . . 247Sun Fire SysControl sensor . . . . . . . . . 248

Model objects with associated attributes . . . 249Configuring the sensor . . . . . . . . . 250Troubleshooting the sensor . . . . . . . . 251

Tru64 computer system sensor. . . . . . . . 251Configuring the sensor . . . . . . . . . 252Troubleshooting the sensor . . . . . . . . 253

VMware ESX computer system sensor . . . . . 253Configuring the sensor . . . . . . . . . 256Troubleshooting the sensor . . . . . . . . 257

Windows computer system sensor . . . . . . 260Configuring the sensor . . . . . . . . . 261Troubleshooting the sensor . . . . . . . . 263

Chapter 7. Storage sensors . . . . . 267Fibre Channel switch sensor . . . . . . . . 267

Model objects with associated attributes . . . 267Configuring the sensor . . . . . . . . . 267Troubleshooting the sensor . . . . . . . . 268

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

Host storage sensor . . . . . . . . . . . 270Model objects with associated attributes . . . 270Configuring the sensor . . . . . . . . . 272Troubleshooting the sensor . . . . . . . . 274

IBM Tivoli Storage Productivity Center sensor . . 276Model objects with associated attributes . . . 277Configuring the sensor . . . . . . . . . 282Troubleshooting the sensor . . . . . . . . 284

Storage sensor . . . . . . . . . . . . . 288Configuring the sensor . . . . . . . . . 288Troubleshooting the sensor . . . . . . . . 289

Veritas Storage Foundation sensor . . . . . . 289Configuring the collation.properties file entries 290Troubleshooting the sensor . . . . . . . . 290

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

Contents v

vi Application Dependency Discovery Manager: Sensors

Figures

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

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

© Copyright IBM Corp. 2008, 2012 vii

viii Application Dependency Discovery Manager: Sensors

Tables

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



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

5. Sensors that support asynchronous orscript-based discovery . . . . . . . . . 7

6. Sensors that support discovery using IBM TivoliMonitoring . . . . . . . . . . . . . 8

7. Required WebLogic JAR files . . . . . . 1168. Configuration parameters . . . . . . . 1649. Foundry OID mapping example . . . . . 181

10. Level 2 bridge topology data . . . . . . 191

© Copyright IBM Corp. 2008, 2012 ix

x Application Dependency Discovery Manager: Sensors

About this information

The purpose of this PDF document is to provide the related topics from theinformation 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 forthe respective sensor, also includes configuration and troubleshooting information.For some sensors, information about the attributes that are associated with themodel objects is also included. Where attributes are included, the attributes areavailable in the IBM® Tivoli® Common Data Model (CDM) but are not necessarilyshown in the IBM Tivoli Application Dependency Discovery Manager (TADDM)UI.

Sensors and supported target systems

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

Discovery process overview

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

Late-breaking updates

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

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

Level 1 discovery profileThese 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 Profileswindow in the TADDM UI.

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

SensorSensor name that is used in the UI andlogs

“Anchor sensor” on page 155 AnchorSensor

“SNMP Light sensor” on page 215 SnmpLightSensor

“Stack Scan sensor” on page 170 StackScanSensor

© Copyright IBM Corp. 2008, 2012 1

http://www.ibm.com/developerworks/wikis/display/tivoliaddm/Home

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






“IBM AIX computer system sensor” on page225

AixComputerSystemSensor

“Alteon port sensor” on page 184 AlteonPortSensor

“Alteon SNMP sensor” on page 185 AlteonSnmpSensor

“Alteon VLAN sensor” on page 186 AlteonVlanSensor


“Asynchronous discovery sensor” on page156

ASDSensor

“BIG-IP port sensor” on page 187 BigIPPortSensor

“BIG-IP SNMP sensor” on page 188 BigIPSnmpSensor

“BIG-IP VLAN sensor” on page 189 BigIPVlanSensor

“Bridge SNMP 2 sensor” on page 192 BridgeSnmpSensor2

“Bridge SNMP sensor” on page 190 BridgeSnmpSensor

“Cisco Discovery Protocol sensor” on page196

CdpSensor

“Check Point SNMP sensor” on page 194 CheckpointSnmpSensor

“Cisco IOS sensor” on page 198 CiscoIOSSensor

“Cisco port sensor” on page 199 CiscoPortSensor

“Cisco VLAN sensor” on page 200 CiscoVlanSensor

“Custom application server sensor” on page157

CustomAppServerSensor

“Custom MIB2 computer system sensor” onpage 158

CustomMib2ComputerSystemSensor

“Entity MIB sensor” on page 202 EntityMIBSensor

“Extreme VLAN sensor” on page 203 ExtremeVlanSensor

“Generic computer system sensor” on page158

GenericComputerSystemSensor

“Generic server sensor” on page 159 GenericServerSensor

“IBM Hardware Management Consolesensor” on page 230

HmcSensor

“Host resources sensor” on page 269 HostResourcesSensor

“HP-UX computer system sensor” on page222

HpUxComputerSystemSensor

“IBM i computer system sensor” on page237

I5OSComputerSystemSensor

“IP device sensor” on page 167 IpDeviceSensor

2 Application Dependency Discovery Manager: Sensors

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


“IPSO computer system sensor” on page 238 IPSOComputerSystemSensor

“IBM Integrated Virtualization Managersensor” on page 236

IvmSensor

“LAN Manager SNMP sensor” on page 207 LanManagerSnmpSensor

“Linux computer system sensor” on page239

LinuxComputerSystemSensor

“NetScreen SNMP sensor” on page 211 NetscreenSnmpSensor

“Nokia SNMP sensor” on page 212 NokiaSnmpSensor

“OpenVMS computer system sensor” onpage 243

OpenVmsComputerSystemSensor

“Ping sensor” on page 168 PingSensor

“Port sensor” on page 169 PortSensor

“Session sensor” on page 170 SessionSensor

“SNMP MIB2 sensor” on page 216 SnmpMib2Sensor

“Solaris computer system sensor” on page243

SunSparcComputerSystemSensor

“Sun Fire SysControl sensor” on page 248 SysControlSensor

“Tru64 computer system sensor” on page251

Tru64ComputerSystemSensor

“VMware ESX computer system sensor” onpage 253

VmwareComputerSystemSensor

“Windows computer system sensor” on page260

WindowsComputerSystemSensor

“Solaris zones generic sensor” on page 247 ZonesGenericSensor






“Active Directory sensor” on page 11 ActiveDirectorySensor



“Alteon port sensor” on page 184 AlteonPortSensor

“Alteon SNMP sensor” on page 185 AlteonSnmpSensor

“Alteon VLAN sensor” on page 186 AlteonVlanSensor


“Apache sensor” on page 12 ApacheServerSensor

Chapter 1. Overview 3



“Asynchronous discovery sensor” on page156

ASDSensor

“BIG-IP port sensor” on page 187 BigIPPortSensor

“BIG-IP SNMP sensor” on page 188 BigIPSnmpSensor

“BIG-IP VLAN sensor” on page 189 BigIPVlanSensor

“Bridge SNMP 2 sensor” on page 192 BridgeSnmpSensor2

“Bridge SNMP sensor” on page 190 BridgeSnmpSensor

“SAP CCMS server sensor” on page 96 CCMSServerSensor

“Cisco Discovery Protocol sensor” on page196

CdpSensor

“Check Point sensor” on page 193 CheckpointSensor

“Check Point SNMP sensor” on page 194 CheckpointSnmpSensor

“Cisco IOS sensor” on page 198 CiscoIOSSensor

“Cisco port sensor” on page 199 CiscoPortSensor

“Cisco VLAN sensor” on page 200 CiscoVlanSensor

“CiscoWorks sensor” on page 201 v CiscoWorks405FileUDS

v CiscoWorks405UDS

v CiscoWorksFileUDS

v CiscoWorksSensor

v CiscoWorksUDS

“Citrix server sensor” on page 15 CitrixServerSensor

“Custom application server sensor” on page157


“Custom MIB2 computer system sensor” onpage 158


“IBM DB2 sensor” on page 131 v Db2Sensor

v Db2WindowsSensor

“DNS sensor” on page 16 DnsSensor

“IBM Lotus Domino server sensor” on page27

v DominoDomainSensor

v DominoServerDetailSensor

v DominoInitialSensor

“Entity MIB sensor” on page 202 EntityMIBSensor

“Microsoft Exchange 2007 Server sensor” onpage 81

Exchange2007Sensor

“Microsoft Exchange Server sensor” on page77

ExchangeServerSensor

“Extreme VLAN sensor” on page 203 ExtremeVlanSensor

“Generic computer system sensor” on page158



“IBM High-Availability ClusterMulti-Processing sensor” on page 24

HACMPSensor




“IBM Hardware Management Consolesensor” on page 230

HmcSensor

“Host resources sensor” on page 269 HostResourcesSensor

“HP-UX computer system sensor” on page222


“IBM i computer system sensor” on page237


“Microsoft IIS Web server sensor” on page89

IISWebServiceSensor

“IBM Informix sensor” on page 136 Informix®

“IP device sensor” on page 167 IpDeviceSensor

“iPlanet server sensor” on page 71 IPlanetServerSensor

“IPSO computer system sensor” on page 238 IPSOComputerSystemSensor

“IBM Integrated Virtualization Managersensor” on page 236

IvmSensor

“JBoss server sensor” on page 71 JBoss4xSensor

“LAN Manager SNMP sensor” on page 207 LanManagerSnmpSensor

“LDAP sensor” on page 73 LdapSensor



“Microsoft HyperV sensor” on page 87 Microsoft HyperV Sensor

“IBM WebSphere MQ Server sensor” onpage 67

MQServerSensor

“Microsoft Cluster sensor” on page 74 MSClusterSensor

“NetScreen SNMP sensor” on page 211 NetscreenSnmpSensor

“NFS sensor” on page 91 NFSServerSensor

“Nokia SNMP sensor” on page 212 NokiaSnmpSensor

“OpenVMS computer system sensor” onpage 243


“Oracle Application Server sensor” on page91

v OracleAppOpmnSensor

v OracleAppSensor

“Oracle sensor” on page 142 OracleSensor


“PIX sensor” on page 213 PixSensor



“SAP SLD server sensor” on page 99 SLDServerSensor

“SMB server sensor” on page 101 SMBServerSensor

“SMS server sensor” on page 102 SMSServerSensor

“SNMP MIB2 sensor” on page 216 SnmpMib2Sensor

“Microsoft SQL Server sensor” on page 138 SqlServerSensor




“Storage sensor” on page 288 StorageSensor



“Sybase IQ sensor” on page 152 SybaseIQSensor

“Sybase sensor” on page 147 SybaseSensor

“Sun Fire SysControl sensor” on page 248 SysControlSensor

“IBM Tivoli Storage Productivity Centersensor” on page 276

TPCStorageSensor

“Tru64 computer system sensor” on page251


“Veritas cluster sensor” on page 105 VeritasClusterSensor

“Veritas Storage Foundation sensor” on page289

VeritasStorageSensor

“VMware Virtual Center server sensor” onpage 107

VirtualCenterSensor

“VMware ESX computer system sensor” onpage 253


“WebLogic SSH sensor” on page 123 v WeblogicLauncherSensor

v WeblogicApplicationSensor

v WeblogicDomainSensor

v WeblogicServerSensor

“IBM WebSphere sensor” on page 45 v WebSphereCellSensor

v WebSphereNodeSensor

v WebSphereVersionSensor



“Solaris zones generic sensor” on page 247 ZonesGenericSensor

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

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


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



“IBM Tivoli Utilization sensor” on page 160 OperatingSystemUtilizationSensor





Sensors that support asynchronous or script-based discoveryThese sensors support asynchronous or script-based discovery.

The “Asynchronous discovery sensor” on page 156 is required for asynchronousdiscovery.

Table 5 lists the sensors that support asynchronous or script-based discovery.

Notes:

1. Asynchronous and script-based discovery is supported only if the targetcomputer system is running the AIX®, Linux (on x86 systems only), or Solarisoperating 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





“IBM DB2 sensor” on page 131 Db2Sensor

“IBM Lotus Domino server sensor” on page27

DominoInitialSensor





MQServerSensor

“IBM Tivoli Utilization sensor” on page 160 OperatingSystemUtilizationSensor

“Oracle sensor” on page 142 OracleSensor



“WebLogic SSH sensor” on page 123 WeblogicLauncherSensor

“IBM WebSphere sensor” on page 45 WebSphereVersionSensor

Sensors that support discovery using IBM Tivoli MonitoringThese sensors support discovery using IBM Tivoli Monitoring.

The “IBM Tivoli Monitoring Scope sensor” on page 31 is required for discoveryusing IBM Tivoli Monitoring. This sensor must be run at least once to create thenecessary scope sets.

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


Monitoring session, without including the IBM Tivoli Monitoring Scope sensor inthe Level 2 and Level 3 discovery profiles.

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

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

the TADDM Administrator's Guide for information about configuring fordiscovery of Windows systems.

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

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

Table 6. Sensors that support discovery using IBM Tivoli Monitoring





“IBM DB2 sensor” on page 131 Db2Sensor





MQServerSensor

“Storage sensor” on page 288 StorageSensor



“WebLogic SSH sensor” on page 123 WeblogicLauncherSensor

“IBM WebSphere sensor” on page 45 WebSphereVersionSensor




Sensor setup problemsThis information covers common problems that occur with sensor setup in the IBMTivoli Application Dependency Discovery Manager (TADDM).

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

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

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

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

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

v Install the LiSt Open Files (lsof) program on all host computersaccording to the requirements in lsof requirements in the TADDM Wiki athttp://www.ibm.com/developerworks/wikis/display/tivoliaddm/Home.

On Linux, Solaris, AIX, and Linux on System z operatingsystems, discovery never ends

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

SolutionAccess to the sudo command must be configured so that the TADDM user,which is the user that starts the TADDM server, can run sudo commandswithout having the password prompt displayed. To configure the sudoaccess in this way, complete the following steps:1. Login to the TADDM server as the root user.2. Enter the visudo command.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 followingcommands:cd $COLLATION_HOME/binsh ./stop-local-anchors.sh

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




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

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

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


Chapter 2. Application sensors

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

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

Sensor name that is used in the GUI and logs

ActiveDirectorySensor

Security issues

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

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

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

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

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

sys.ActiveDirectory

v Hostv InitRecvTimeoutv MaxConnIdleTimev MaxConnectionsv MaxDatagramRecvv MaxNotificationPerConnv MaxPageSizev MaxPoolThreadsv MaxQueryDurationv MaxReceiveBufferv MaxResultSetSizev MaxTempTableSizev MaxValRangev NamingContextsv Name


v RootDomainv SchemaVersionv ServiceXMLv WorkingDirectory

sys.ServiceAccessPoint

v ContextIpv BindAddressv Namev ProductNamev ProductVersionv VendorName

sys.NamingContext

v Indexv Value

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

Configuring the scope

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

Configuring the access list

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

Configuring the discovery profile

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

Apache sensorThe Apache sensor discovers Apache Web servers.


ApacheServerSensor

Prerequisites

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

Limitations

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


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

Model objects created

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

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

Sensor configuration requirements

For asynchronous discovery, the sensor requires no configuration.

See the TADDM Administrator's Guide for information about configuring forscript-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 fornonscript-based discovery.

Limitations

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

Application descriptor discovery is not supported.

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

Chapter 2. Application sensors 13

Only running applications are discovered.


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

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

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the sensor uses.

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

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

HOSTNAME:LISTENINGIP:PORT

The default value of this property is false.

You must manually delete the HOSTNAME:PORT instances.

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

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

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

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

Discovery error with “cannot execute httpd”

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

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

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


Apache sensor fails with error CTJTD0072E

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

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

Many fields in the Details panel are empty

ProblemA number of fields in the Details panel are empty.

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

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


CitrixServerSensor

Security issues

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

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

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

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

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


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

The Citrix sensor runs slowly

ProblemThe Citrix sensor runs slowly on systems overloaded with many publishedCitrix applications. (WMI queries take a long time)

SolutionIncrease the sensor timeout by setting the following property in thecollation.properties file:

com.collation.discover.agent.CitrixServerAgent.sessiontimeout=300000

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


DnsSensor


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

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

Sensor fails to discover a DNS server

ProblemThe sensor is unable to discover a running DNS server.

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

HIS sensorThe HIS sensor discovers a Microsoft Host Integration Server.


HISServerSensor

Prerequisites

Before you run this sensor, the following prerequisites must be met:v The discovery of the Windows Computer System must succeed.v The SNABase service must be running.


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

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


app.his.HISDomain

v APPCModesv AuditLevelv BroadcastMeanTimev BroadcastProtocolIpxSpxv BroadcastProtocolNamedPipesv BroadcastProtocolTcpIpv ClientBackupDomainNamesv ClientBackupSponsorNamesv ClientDomainBackupTypev ConfigServerv DisplayNamev DisplayVerbConnectionv DomainNamev EventLogServerNamev NetViewConnectionv PopupServerNamev RTMEndOfSessionv RTMOverflowv RTMThresholdv RTMTimerUntilv Security3270v SecurityAPPCv SecurityLUAv Serversv Status

app.his.HostIntegrationServer

v DisplayNamev Domainv LinkServicesv Namev ProductNamev ProductVersionv ServerRole


v Servicesv TransportStringv VendorName

app.his.IPDLCService

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

app.his.APPCMode

v AllowLZandRLEv AutoActivatev DisplayNamev EndPointOnlyv IsPriorityv MaxReceiveCompressionv MaxSendCompressionv MinimumContentionWinnerLimitv Namev Parentv PartnerMinimumContentionWinnerLimitv ReceivePacingv ReceiveRuSizev SessionLimitv TransmitPacingv TransmitRuSize

app.his.HISConnection

v Activation


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

app.his.HISLUA

v Compressionv DisplayNamev HighPriorityModev Namev Numberv Parentv Protocolv UserWksSecure

app.his.HISLUDisplay

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

app.his.HISLUPrint

v AssociatedLUv Compression


v HISServicev Namev Numberv Parentv Protocolv UserWksSecure

app.his.PrintService

v Accountv ActivationRetryIntervalv ActivationRetryLimitv AlwaysDoNLv CanBePausedv CanBeStoppedv DelayPrintStartv Descriptionv DesktopInteractv DisplayNamev DoAllFFv ErrorControlv ExitCodev FlushFinalFFv IgnoreCharsUnder3Fv Namev NoEventLogOnSkippingTransparentSectionv NoSpaceAfterFFv OperatingStatev Parentv PathNamev Serverv ServiceNamev ServiceSpecificCodev ServiceTypev SoftwareVersionv StartModev Startedv UseFixedTabsv UseProportionalFontChange

app.his.SNAService

v ControlPointv HISConnectionsv Namev NetworkNamev Parentv Server



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

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

WMI service fails on a target during discovery

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

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

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


CSMServerSensor and CSMNodeSensor

Prerequisites

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


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


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

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

CSMServerAgentConfiguration.


2. Set the following required attributes:

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

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

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

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

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

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

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

The default value is 1.

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

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

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

The default value is "*".

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

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


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

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



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

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


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

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


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

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

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


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

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

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


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

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

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


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

doPingNodesSpecifies whether ping sensors are run against discovered CSM nodes.


There are no specific sensor setup requirements associated with theCSMNodeSensor.


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

CSMNodeSensor uses ComputerSystem access entry to access CSM nodes.

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


HACMPSensor

Prerequisites

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

Security issues

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

Limitations

The following limitations apply:v TADDM supports only Apache servers that are running on the HACMP cluster.v Only one application server can run on the HACMP resource group.

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


HACMPAppResource

v AppServerv LocalAppResourcesv Namev Parent


HACMPCluster

v ClusterIDv ComputerSystemsv ConnAuthModev HeartbeatNetworksv MessageAuthModev MessageEncryptionv Nodesv ResourceGroupsv Statev Substatev UsePersistentLabel

HACMPClusterHeartbeatNetwork

v Namev Netmaskv NetworkElementsv Parentv PrefixLengthv Type

HACMPClusterHeartbeatNetworkElement

v L2Interfacev Namev NetworkAddressv Parentv StorageVolumev Type

HACMPClusterManager

v CurrentStatev HacmpNode

HACMPLocalAppResource

v Nodev Parentv StartScriptv StopScript

HACMPLocalResourceGroup

v LocalStatev Nodev Parent

HACMPNode

v ClusterManagerv LocalAppResourcesv LocalResourceGroupsv Namev NetworkElements


v Parentv SiteInfov Statev System

HACMPResourceGroup

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

ServiceIPLabel

v IpAddressv Namev Parent

SiteInfo

v Name


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

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

use for authentication to the target computer system.

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

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

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


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

HACMP cluster is duplicated

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

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

Incorrect HACMP version returned

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

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

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

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

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

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


DominoDomainSensor, DominoServerDetailSensor, and DominoInitialSensor

Prerequisites

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

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

servers to the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.2.0/


plugin.xml file. You can append the port number of the Domino IIOP server tothe server name. Adding the port number is optional. Typically, the default portnumber is 63148 for Domino Internet Inter-ORB Protocol (DIIOP). If anonymousaccess is required, the port number is 80 for HTTP.The following example illustrates how to add an IIOP server name:<IIOPServers>

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

</item><item>

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

</item></IIOPServers>

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

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

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

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

v For TADDM to connect to a Domino IIOP server using SSL, you must set theosgi/plugins/com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.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. TheTrustedCerts.class file is located in the domino data folder/domino/javafolder.

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

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

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

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


The sensor creates the following model objects:v app.lotus.AgentManagerv app.lotus.AdminProcessv app.lotus.DirectoryAssistancev app.lotus.DirectoryCatalogerv app.lotus.DomainCatalogv app.lotus.DominoClusterv app.lotus.DominoConnectionv app.lotus.DominoDatabase


v app.lotus.DominoDomainv app.lotus.DominoNamingContextv app.lotus.DominoReplicasv app.lotus.DominoSecurityv app.lotus.DominoServerv app.lotus.DominoTransactionLoggingv app.lotus.HTTPFilterSpecialtyServerv app.lotus.IIOPConfigv app.lotus.IMAPConfigv app.lotus.InternetClusterManagerv app.lotus.LDAPConfigv app.lotus.OtherDatabasev app.lotus.POPConfigv app.lotus.RemoteDebugManagerv app.lotus.SMTPConfigv app.lotus.SpecialityServerv app.lotus.WebConfigv app.lotus.WebRetriever

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






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

Limitations

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

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



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

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

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

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

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

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

The sensor does not start

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

Solution

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 theplugin.xml file, you must restart the TADDM server for the changes totake effect.

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

– show tasks

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

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

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

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


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

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

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

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

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


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

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

Prerequisites

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

Limitations

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

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

Tivoli Monitoring server, Tivoli Monitoring discovery is not successful.

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

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


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


net.IpInterface

v IpAddress

Multiple computer systems, with the following model objects:

sys.aix.AixUnitaryComputerSystemsys.hpux.HpUxUnitaryComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.Solarissys.sun.SunSPARCUnitaryComputerSystemsys.UnitaryComputerSystem

sys.windows.WindowsComputerSystemsys.zOS.ZSeriesComputerSystem

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

Multiple operating systems, with the following model objects:

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

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

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


Copying necessary files from the Tivoli Enterprise Portal Serverto the TADDM serverYou must copy some files from the Tivoli Enterprise Portal Server to the TADDMserver.

In a streaming server deployment, perform these steps on the discovery server, ifyou are configuring the sensor for the first time. You do not complete thisprocedure if you already copied the files from the Tivoli Enterprise Portal Server tothe TADDM server 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/itmdirectory on the TADDM server:v browser.jar

v cnp.jar

v cnp_vbjorball.jar

v kjrall.jar

v util.jar

v tap_cli.jar

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

3. 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/itmdirectory on the TADDM server.On Windows systems, copy the file from the ITM_INSTALLATION_DIR\GSK7\classes directory.On Linux and UNIX systems, copy the file from the ITM_INSTALLATION_DIR/ARCH/gs/classes directory.

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

5. Restart the TADDM server.

Distributing the discovery target support bundleDuring the discovery process, the IBM Tivoli Application Dependency DiscoveryManager (TADDM) must copy binary file data between itself and the discoverytarget using IBM Tivoli Monitoring as an intermediary. For Windows discoverytargets, the discovery target support enables binary files to be copied fromTADDM to the discovery target as part of the discovery process. The discoverytarget support bundle also provides part of the Windows gateway on the target sothat the gateway is available during discovery. This method prevents you fromhaving to deploy a separate Windows discovery gateway within your TivoliMonitoring environment. The discovery target support bundle is not required onLinux, AIX, Solaris, and HP-UX operating systems.

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


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

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

In addition to deploying the discovery target support bundle, you must ensure thateach Tivoli Monitoring endpoint is configured for discovery. For example, eachUNIX-based endpoint must have the LiSt Open Files (lsof) program installed. Formore information, see the topic “Configuring target computer systems” in the“Administering” topics in the IBM Tivoli Application Dependency DiscoveryManager information center.

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

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

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

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

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

Validating user...

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

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

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

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

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

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

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

Validating user...

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

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


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

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

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

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

3. To obtain the managed system names for the Windows operating systems, usethe tacmd listSystems -t NT command. For more information about the tacmdlistSystems -t NT command, see tacmd CLI commands at:http://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 Serverto the discovery targets, log in to the Tivoli Enterprise Monitoring Server, andrun the tacmd command, as shown in the following sample:

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

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

Validating user...

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

KUICAR010I: The agent type d7 is being deployed.

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

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

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

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

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


http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.2fp2/tacmd.htm

http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.2fp2/tacmd.htm

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

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

Installing on Linux operating system:

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

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

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

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

Installing on Windows operating system:

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

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

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

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

Configuring the discovery profileBy default, the IBM Tivoli Monitoring Scope sensor is not enabled. After youenable it, TADDM discovers Tivoli Monitoring endpoints and creates a scope set.The scope set contains the discovered endpoints and uses the default TivoliEnterprise Portal Server port 1920. However, by default, computer system objectsare not created for the Tivoli Monitoring endpoints. If you want to create computersystem objects for each discovered endpoint or to use a Tivoli Enterprise PortalServer port other than 1920, create a new Level 1 or Level 2 discovery profile forthe 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.


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

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

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

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

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

9. Click OK to return to the Discovery Profiles window.10. In the Discovery Profiles window, click Save.

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

Procedure1. 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 byITM, and runs a session sensor. The sensor uses the ITM session only if it isallowed and preferred for the host.

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

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


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

2. To create an access list, click the Access List icon.3. In the Access List window, click Add.4. In the Component Type field of the Access Details window, click IBM Tivoli

Monitoring.


5. Type the credentials for the Tivoli Enterprise Portal Server. Use the credentialsthat are required to log in to the Tivoli Enterprise Portal Server rather than thecredentials for the computer on which the Tivoli Enterprise Portal Serverresides.

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

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

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

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

click Delete for each one.

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

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

for the IBM Tivoli Monitoring, and click Delete.

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

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

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

Uninstall on Linux operating system:

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

2. Run the uninstall query:/opt/IBM/ITM/bin/itmcmd execute cq"/opt/IBM/ITM/li6263/cq/bin/KfwSQLClient -d KFW_DSN–f /tmp/teps/uninstall_zkd7.sql"

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

4. Start the Tivoli Enterprise Portal Server:


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

Uninstall on Windows operating system:

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

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

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

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

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

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

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

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

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

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

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

To delete the files copied from the Tivoli Enterprise Portal Server, complete thefollowing steps:1. On the TADDM server, delete the $COLLATION_HOME/osgi/plugins/

com.ibm.cdb.session.itm_7.2.1.1/lib/itm directory.2. Restart the TADDM server.

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


Computer systems that are outside of the defined scope arecreated

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

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

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

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

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

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

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

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

SolutionIn the etc/collation.properties file, edit the following property, wherevalue is the number of milliseconds allowed for the sensor to run (forexample, 60000 is 1 minute):com.collation.discover.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 ormany router hops exist between the target systems and theTivoli Enterprise Portal Server or TADDM

ProblemThe Tivoli Monitoring Scope sensor fails with a timeout error. Slownetwork links or many router hops exist between the target systems andthe Tivoli Enterprise Portal Server or TADDM. The environment includesWindows, Linux, and UNIX systems.

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


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

On AIX systems:

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


On Linux systems:

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

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

# increase Linux autotuning TCP buffer limits

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

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

On Solaris systems:

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


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

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

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

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

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

SolutionThese messages do not indicate actual errors, because the discovery targetsupport bundle is not intended to respond to the agent start or stopcommand. The Tivoli Monitoring cinfo command also does not list thesupport bundle, because the support bundle is an addition to the existingOS agent.

Verify that the discovery target support bundle is correctly installed on thediscovery target. From the Tivoli Monitoring directory on the targetcomputer, run the directory command as shown in the following example:


C:\Documents and Settings\Administrator>cd %CANDLEHOME%

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

Directory of C:\IBM\ITM\taddm

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

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

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

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

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

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

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

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

program.6. Click Recycle.

Temporary files are in the log directory of the target system

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


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

Trailing white spaces exist in the output from discovery targets

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

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

After upgrading IBM Tivoli Monitoring, errors occur duringdiscovery

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

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

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

page 35

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

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

page 35v “Configuring the discovery profile” on page 36v “Configuring the access list” on page 37

Errors occur during discovery of a Tivoli Monitoring 6.2.2environment

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

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

SolutionVerify that the Tivoli Enterprise Monitoring Server process on the Tivoli


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

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

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

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

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

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

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

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

Too many active report queries on the Tivoli Enterprise PortalServer

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

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

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


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

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

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


WebSphereCellSensor, WebSphereJDBCDriverSensor, WebSphereNodeSensor, andWebSphereVersionSensor

Prerequisites

For IBM WebSphere Virtual Enterprise discoveries, you must install and run theIBM WebSphere Network Deployment Manager system and IBM WebSphereVirtual Enterprise. Also, at least one dynamic cluster must be defined.

For IBM WebSphere JDBC driver discoveries, ensure that the followingprerequisites 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 alsoensure that the user has permission to write to the directory containing the JDBCdriver 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 applicationlevels are not resolved.

v JDBC connections that use native DB aliases configured in native DB clients arenot supported.

v Distributed WebSphere servers cannot be discovered on their own. Thediscovery is done from the dmgr (cell manager). To discover this machine, itmust be in the discovery scope. If it is not in the discovery scope, thelocal-anchor log shows the following messages:


– 2008-05-17 11:52:54,375 [Thread: 0,8495] WARN j2ee.WebSphereAgent -[WebSphereAgent.W.7] verifyStandaloneServer() determined cell to bedistributed (DISTRIBUTED), terminating discovery

– 2008-05-17 11:52:54,379 [Thread: 0,8495] WARN j2ee.WebSphereAgent -[WebSphereAgent.W.2] Terminating discovery of managed server/nodeagentportfolio_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) sendMessageto:127.0.0.1:ReplyMsg:(#4):ip=null,host=localhost:MSG_SUCCESS:::resultclass: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) sendMessageto:127.0.0.1:StatsMsg:(#5):ip=null,host=localhost:1 connections,0classes,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 isdiscovered for each server that is running. The discovery of the runtimeinformation is dependent on cell and node agent synchronization.Synchronization must be enabled for every node within a cell. Thesynchronization interval determines how up to date the discovery is. The mostcurrent information is gathered from the cell after the JVM information ispropagated from the node agent.

v When discovering a distributed WebSphere Application Server, the JDBC driverversion is discovered only for JDBC providers that have a class path valid forthe host running the deployment manager process.

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


The sensor creates the following model objects:v app.AppConfigv app.AppServerv app.ConfigFilev app.SoftwareContainerv app.j2ee.J2EEComponentv app.j2ee.J2EEDeployedObjectv app.j2ee.J2EEModulev app.j2ee.J2EEResourcev app.j2ee.JDBCDriverv app.j2ee.websphere.WebSphereAuthMappingModulev app.j2ee.websphere.WebSphereCell


v app.j2ee.websphere.WebSphereClusterv app.j2ee.websphere.WebSphereConfiguredConnectionv app.j2ee.websphere.WebSphereConnectorv app.j2ee.websphere.WebSphereConnectorModulev app.j2ee.websphere.WebSphereCustomUserRegistryv app.j2ee.websphere.WebSphereDeploymentManagerv app.j2ee.websphere.WebSphereDynamicCachev app.j2ee.websphere.WebSphereEFixInfov app.j2ee.websphere.WebSphereEJBv app.j2ee.websphere.WebSphereEJBModulev app.j2ee.websphere.WebSphereGlobalSecuritySettingsv app.j2ee.websphere.WebSphereJ2EEApplicationv app.j2ee.websphere.WebSphereJ2EEResourcev app.j2ee.websphere.WebSphereJ2EEResourcePropertyv app.j2ee.websphere.WebSphereJDBCConnectionPoolv app.j2ee.websphere.WebSphereJDBCDataSourcev app.j2ee.websphere.WebSphereJDBCProviderv app.j2ee.websphere.WebSphereJMSDestinationv app.j2ee.websphere.WebSphereJMSProviderv app.j2ee.websphere.WebSphereJMSQueuev app.j2ee.websphere.WebSphereJMSTopicv app.j2ee.websphere.WebSphereLDAPUserRegistryv app.j2ee.websphere.WebSphereLibraryRefv app.j2ee.websphere.WebSphereMQJMSDestinationv app.j2ee.websphere.WebSphereMQJMSQueuev app.j2ee.websphere.WebSphereMQJMSTopicv app.j2ee.websphere.WebSphereNamedEndpointv app.j2ee.websphere.WebSphereNodev app.j2ee.websphere.WebSphereNodeAgentv app.j2ee.websphere.WebSphereServletv app.j2ee.websphere.WebSphereServerv app.j2ee.websphere.WebSphereSessionTuningParamsv app.j2ee.websphere.WebSphereSharedLibraryv app.j2ee.websphere.WebSphereSSLSettingsv app.j2ee.websphere.WebSphereUserRegistryv app.j2ee.websphere.WebSphereVariablev app.j2ee.websphere.WebSphereVirtualHostv app.j2ee.websphere.WebSphereWebModulev app.JVM

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







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

Limitations

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


The following model objects are not supported:v app.j2ee.websphere.WebSphereClusterv app.j2ee.websphere.WebSphereConfiguredConnectionv app.j2ee.websphere.WebSphereConnectorv app.j2ee.websphere.WebSphereConnectorModulev app.j2ee.websphere.WebSphereCustomUserRegistryv app.j2ee.websphere.WebSphereDynamicCachev app.j2ee.websphere.WebSphereEFixInfov app.j2ee.websphere.WebSphereGlobalSecuritySettingsv app.j2ee.websphere.WebSphereJMSDestinationv app.j2ee.websphere.WebSphereJMSProviderv app.j2ee.websphere.WebSphereJMSQueuev app.j2ee.websphere.WebSphereJMSTopicv app.j2ee.websphere.WebSphereLDAPUserRegistryv app.j2ee.websphere.WebSphereLibraryRefv app.j2ee.websphere.WebSphereMQJMSDestinationv app.j2ee.websphere.WebSphereMQJMSQueuev app.j2ee.websphere.WebSphereMQJMSTopicv app.j2ee.websphere.WebSphereNodeAgentv app.j2ee.websphere.WebSphereServletv app.j2ee.websphere.WebSphereSessionTuningParamsv app.j2ee.websphere.WebSphereSharedLibraryv app.j2ee.websphere.WebSphereSSLSettingsv app.j2ee.websphere.WebSphereUserRegistryv app.j2ee.websphere.WebSphereVirtualHostv app.JVM

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


Enabling JDBC driver discoveryIf you want to discover JDBC driver information, you must enable the WebSphereJDBC driver sensor.

To enable the WebSphere JDBC driver sensor, complete the following steps:1. Create a Level 3 discovery profile.2. For the WebSphere cell sensor, enable the deepDiscoveryLevel configuration

item.3. Enable the WebSphere JDBC driver sensor in the new discovery profile.4. Set the appropriate configuration options for the WebSphere JDBC driver

sensor. The following configuration options are available:v You can configure for a prefix to be added to every command run by the

WebSphere JDBC driver sensor on the target host. You can configure adifferent prefix for UNIX and Windows systems. By default, a prefix is notdefined.

v You can configure for the sensor to remove the OracleUtility file afterdiscovery completes. The OracleUtility file is an auxiliary file used byTADDM on target hosts to discover JDBC driver information for Oracledatabases. By default, the OracleUtility file is not removed.

Configuring the discovery profileIf you want to change the discovery level, update the discovery profile for the IBMWebSphere sensor.

To change the default the discovery level for this sensor, complete the followingsteps:1. In the Discovery Profiles window, click New.2. In the Create New Profile window, type the profile name, description, and

click OK.3. In the list of sensors, click the WebSphereCellSensor, and click New.4. In the Create Configuration window, type the name and description for your

configuration of the WebSphereCellSensor, and select the EnableConfiguration check box.

5. In the Configuration section of the Create Configuration window, to changethe discovery level value, select one of the following choices:v To enable medium discovery, double-click the value for

mediumDiscoveryLevel and change from false to true

v To enable deep discovery, double-click the value for deepDiscoveryLeveland change from false to true

If deepDiscoveryLevel is set to true, it runs a deep discovery regardless ifshallow and medium discoveries are set to true or false.

6. Optional: To configure the sensor to discover only servers that are running,click discoverStoppedServers. Then double-click the Value field in the row,and type false.

7. Click OK to return to the Discovery Profiles window.8. Ensure the WebSphereVersionSensor and WebSphereNodeSensor are selected

along with the new WebSphereCellSensor configuration you created.9. In the Discovery Profiles window, click Save.

10. Choose this discovery profile when running a discovery.


For more information about Discovery Profiles, see the “Using” topics in the IBMTivoli Application Dependency Discovery Manager information center.

Sensor properties

shallowDiscoveryLevel, mediumDiscoveryLevel, deepDiscoveryLevel

The WebSphere sensor has three discovery levels, shallow, medium, anddeep. By default the shallow discovery level is enabled. To modify thediscovery level value, select one of the following choices:v To enable medium discovery, double-click the value of

mediumDiscoveryLevel and change false to true.v To enable deep discovery, double-click the value of deepDiscoveryLevel

and change from false to true.

If the deepDiscoveryLevel is set to true, it runs a deep discovery regardlessof whether shallow and medium discoveries are set to true or false.v The following list contains the information that is captured at each

discovery level.– Shallow discovery discovers the following components:

- Application descriptor files- Cell, node, server names- Cell, node, server type- Host system- JVM runtime version for every running server- Product name and version- Root directory

– Medium discovery discovers the following components:- Clusters- Configuration files- Connections- Deployed connector modules- Deployed EJB modules- Deployed 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


- 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 theWebSphere client code called by the TADDM WebSphere sensor. samplevalue - Admin=all=enabled

Caution: The preceding value generates verbose trace logging. Not settingany value prevents trace logging.

traceOutputFile

Allows you to specify the full path name of the output file to be used forlogging trace output. Leave this property blank if tracing is not required.

TADDM user must have permission to create the output file.

ffdcLogDirectory

Enables FFDC logs of the WebSphere client code called by the WebSpheresensor for troubleshooting purposes. FFDC logs capture the failure paththrough the WebSphere client code in a subdirectory named ffdc in thedirectory specified in this property.

Not setting a value ensures that FFDC is not enabled. The directory mustexist and the TADDM user must have write access.

Configuring the access listThis topic describes the access details you require depending on type ofconfiguration 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 passwordb. 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 WebSphereJDBC driver sensor will try to log in with ComputerSystem credentials.

4. The WebSphere Application Server user can have monitor, operator,configurator, or administrator role. Any of these roles can discover all theinformation. Only the administrator role discovers security configurationinformation for WebSphere Application Server.

5. Disabling security does not mean that you are not using SSL. Check whetheryou are prompted for a password when you connect to the WebSphereApplication Server Admin Console.


v If you need only a user name to log on to the Admin Console, security isdisabled.

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 inyour web browser), you need the certificates.

Certificate setup

If security is enabled when discovering WebSphere Application Server, TADDMrequires that SSL certificates are set in the access list entries. TADDM supportsPKCS12 and JKS certificate store types. The truststore and keystore files must bepresent on the computer running the TADDM console, not the TADDM server.

Truststore and keystore files are typically found in the $PROFILE_HOME/etc directoryon the system where WebSphere Application Server is installed. By default, thefollowing files are certificate stores:v PKCS12

– $PROFILE_HOME/etc/trust.p12

– $PROFILE_HOME/etc/key.p12

v JKS– $PROFILE_HOME/etc/DummyClientTrustFile.jks

– $PROFILE_HOME/etc/DummyClientKeyFile.jks

The default passphrase for these files is WebAS. You can also create truststore andkeystore files by downloading certificates using the WebSphere Application Serverconsole.

TADDM requires a truststore with signer certificate only for connecting with dmgr,in the case of WebSphere Application Server Network Deployment (ND), andserver1, in the case of a stand-alone server.

Because of the restrictions of the JMX protocol, which is used to retrieve data fromWebSphere Domain Manager or from a stand-alone server (certificates caching persession), TADDM can handle only one truststore file for a single discovery. Thecertificates that are stored in the truststore file are loaded when connection withWebSphere Application Server is established. Only those certificates can be used byTADDM during the entire discovery, so if certificates from several truststores arerequired, attaching them separately into appropriate access list entries won't work.You must export the original truststores to a single file. When all necessary entriesfor each WebSphere server are created in the TADDM access list (one for eachdifferent login/password combination for discovered WebSphere servers), the veryfirst 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 forJKS, the .jks files) that contain all required certificates, complete the followingsteps: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.


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 .jksfiles. To do this for the default DummyServerTrustFile.jks andDummyClientTrustFile.jks files, complete the following steps (if you are usingPKCS12 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/bindirectory.

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 onesDummyClientTrustFile.jks and DummyClientKeyFile.jks, or trust.p12 andkey.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 Filesv In general, the WebSphere Application Server sensor captures the following

configuration files:– WebSphere Application Server cell– WebSphere Application Server node– WebSphere Application Server serverThis information is made available for the change history over time. It is alsomade visible in the Discovery Management Console (Configuration files tab ofthe Details panel) for each of the preceding configuration items.

v When the sensor starts, it also uses the following two files to make key decisionsabout the discovery of WebSphere Application Server:– $WAS_ROOT/config/cells/cell_name/cell.xml


This helps to determine if the system is ND or stand-alone WebSphereApplication Server. If read access to this file is not available, the sensorcontinues and uses JMX to determine whether it is an ND or stand-aloneWebSphere Application Server.

– $WAS_ROOT/config/cells/cell_name/nodes/node_name/serverindex.xml (forND, node_name is the dmgr's node, for stand-alone mode, there is only onenode)This helps to determine the port on which the JMX SOAP connector islistening. If read access to this file is not available, the sensor attempts to setup a JMX connection by cycling through all the listen ports of the WebSphereApplication Server server/dmgr being discovered. The ports are tried inascending order since this method results in quicker identification of the JMXport.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the IBM WebSpheresensor uses.

com.collation.discover.localanchor.timeout=7200000com.collation.discover.agent.WebSphereAgent.timeout=7200000com.collation.discover.agent.WebSphereNodeSensor.timeout=7200000

The default value is 7200000, which means 7,200,000 milliseconds (or 2hours).

These properties set the time allowed for the WebSphere sensor to run.

If you have a large WebSphere environment and require medium or deepdiscovery levels, you might need to increase the value so that the sensorhas enough time to discover the environment.

com.collation.discover.websphere.jmx.timeout=This property sets the time allowed for opening a JMX connection toWebSphere. By default, the value is 600000 milliseconds (10 Minutes)

com.collation.discover.agent.WebSphereVersionAgent.versionscript=sudoThis property can be enabled for access to the WebSphere versionInfo.shfile if the discovery user does not have access on the target WebSphereApplication Server system.

Using the WebSphere seed sensor for z/OSTADDM does not support an operating system sensor for a z/OS system. Todiscover WebSphere resources on a z/OS system, the WebSphere sensor isenhanced to support discovery initiated from user-created seed files.

Because there is no z/OS system sensor, you must use the WebSphere ApplicationServer seed utility for the z/OS DLA. This utility creates an XML seed file from az/OS IDML book. This file contains information about the WebSphere resourcesthat you are trying to discover on the z/OS system.

After this seed file is created, on the next discovery, the WebsphereIdmlSeedSensorlooks for z/OS WebSphere seed files on the TADDM server. If there are, it parsesthat seed file and create a real discovery seed file that is used to kick off theWebSphere sensor. The WebSphere sensor then does a deeper discovery ofWebSphere on this z/OS system.

To install and configure the WebSphere Application Server seed utility for thez/OS DLA, see the corresponding section.


Preparing to run the WebSphere seed sensorBefore running the WebSphere seed sensor, you must create a seed file.

Before running the WebSphere seed sensor, complete the following steps:1. Choose the appropriate method to create the WebSphere seed file:

v To discover WebSphere on a z/OS system using the DLA, use the utility thatis provided in the Tivoli Open Process Automation Library (OPAL) athttp://www.ibm.com/software/tivoli/opal. This utility generates the seedfiles automatically from the IDML books created from the z/OS DLA.For information about this utility, see the topic “Installing the WebSphereApplication Server seed utility for the z/OS DLA.”

v To discover WebSphere on a non-mainframe system by manually creating theseed file, use the following file naming conventions when creating the seedfile:– If you want the file to be included as part of the discovery, the file name

must end with a .xml extension.– The file name must adhere to the following format:

<cellname>_<fqdn>_<port>.xml

An example is c1_0.0.0.0_2809.xml.The following example shows the file format:<IDML_WAS_SEED>

<WAS_ROOT_DIR>/opt/WebSphere/AppServer</WAS_ROOT_DIR><WAS_VERSION>6.0.2.7</WAS_VERSION><SOAP_CONNECTOR_PORT>8880</SOAP_CONNECTOR_PORT><RMI_CONNECTOR_PORT>2809</RMI_CONNECTOR_PORT><JMX_LISTEN_IP_ADDRESS>0.0.0.0</JMX_LISTEN_IP_ADDRESS><HOST_MAPPINGS>

<HOST_MAPPING><HOST_NAME>wasserver.company.com</HOST_NAME><PRIMARY_IP_ADDRESS>0.0.0.0</PRIMARY_IP_ADDRESS><IP_ADDRESS>0.0.0.0</IP_ADDRESS>

</HOST_MAPPING></HOST_MAPPINGS>

</IDML_WAS_SEED>

WAS_ROOT_DIRThe directory path where the WebSphere Application Server isinstalled.

WAS_VERSIONThe version of the WebSphere Application Server, which can befound in the product file in the <WebSphere RootDirectory>/properties/version directory.

SOAP_CONNECTOR_PORTThe port number is retrieved from the serverindex.xml file for theSOAP_CONNECTOR_ADDRESS endpoint name. For example,<WebSphere Root Directory>/profiles/<app server ordmgr>/conf/cells/<cell name>/nodes/<node name>

If the resource is a deployment manager, use the serverindex.xmlfile with the following value specified:serverType="DEPLOYMENT_MANAGER".

If the resource is stand-alone component, use the serverindex.xmlfile with the following value specified:serverType="APPLICATION_SERVER"


http://www.ibm.com/software/tivoli/opal

RMI_CONNECTOR_PORTThe port number is retrieved from the same serverindex.xml fileused to find the soap port, where the endpoint name isBOOTSTRAP_ADDRESS.

JMX_LISTEN_IP_ADDRESSThe IP address that is used to connect through JMX. Typically thisaddress is the same IP address as the WebSphere server.

HOST_MAPPINGSA list of mappings between the host name and IP address for theWebSphere Application Server or Deployment Manager and eachdistributed Node Agent.

HOST_MAPPINGOne host mapping consisting of a host name, primary IP address,and IP address.

HOST_NAMEThe fully qualified domain name.

PRIMARY_IP_ADDRESSThe primary IP address that the host name resolves to.

IP_ADDRESSThe IP address that the host name resolves to, if different from theprimary IP address.

2. Place the .xml files in the $COLLATION_HOME/var/dla/zos/was directory. If thedirectory does not exist, create the directory. The scope of discovery iscontrolled by the files in this directory. If discovery of a particular WebSphereserver is no longer needed, the file must be removed from this directory orrenamed without the .xml extension.

3. Create a new sensor configuration file when you run the WebSphere seedsensor. Change the location of the XML seed file using the following two tags:

<fileName>Set this tag to the directory where the WebSphere XML seed files arelocated.

<scope>Set this tag to the IP address of the TADDM server where theWebSphere XML seed files are located.

Related reference:“Installing the WebSphere Application Server seed utility for the z/OS DLA” onpage 57To discover the WebSphere product on a z/OS system, use the WebSphereApplication Server seed utility for the z/OS DLA. This utility creates the XML seedfiles from the IDML book. If you do not use this utility, you must manually createthe XML seed files.

Running the WebSphere seed sensorThis topic describes how to run the WebSphere seed sensor.

To run the WebSphere seed sensor, complete the following steps:1. Start the TADDM server.2. Open the Discovery Management Console.3. Add the IP address of the server where the WebSphere seed file is located to a

scope.


4. In the Access List, add the access credentials of the server where theWebSphere seed file is located.

5. If security is enabled for the WebSphere server being discovered, add thecredential 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 forexample, Resource Access Control Facility (RACF®) and transferred to a tool formaintaining digital certificates. Use this tool for example iKeyman, to generatea JKS or PKCS12 file. This file contains the client-side SSL certificate in a formatthat can be used by TADDM. The JKS or PKCS12 file must then be used for theSSL settings in the TADDM WebSphere Access List entry for both keystore andtruststore certificates.

6. Complete the following steps:a. Configure the IdmlFileUDS sensor using the Discovery Management

Console:1) In the Discovery Profiles window, click IdmlFileUDS.2) Click New.3) Type the sensor configuration name and description.4) Select Enable Configuration.

5) Double-click /data/latest/dist/var/dla/zos/was and type the location of theWebSphere XML seed files. This location is the server where theWebSphere seed file is located.

6) Double-click 0.0.0.0 and type the IP address of the machine on whichthe seed file is located.

b. Create a discovery profile that includes the following sensors:v Anchor Sensorv Sensor name entered in step a. (The modified IdmlFileUDS sensor created

previously.)v PortSensorv PingSensorv SessionSensorv GenericServerSensorv WebSphereIdmlSeedSensorv WebSphereCellSensorv WebSphereNodeSensorv WebSphereSensor (select this sensor instead of WebSphereCellSensor and

WebSphereNodeSensor only ifcom.collation.websphere.performance.setting=false)

The sensors can require additional sensors to be enabled in the profile bydefault, enable all additional sensors.

c. Save the configuration file.7. Run the discovery and select the scope to include the server and the discovery

profile that you created.

Installing the WebSphere Application Server seed utility for thez/OS DLATo discover the WebSphere product on a z/OS system, use the WebSphereApplication Server seed utility for the z/OS DLA. This utility creates the XML seedfiles from the IDML book. If you do not use this utility, you must manually createthe XML seed files.


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

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

Sensor does not start

ProblemThe WebSphere Application Server sensor does not start.

Solution

To determine why the WebSphere Application Server sensor does not start,validate the following criteria on your WebSphere server:v The WebSphere process is running.v The command line is not truncated (the process that is running must

match the template for the WebSphere Application Server).For Windows 2003/2008, Linux, Solaris, AIX, and Linux on System zoperating systems, the command line must contain the word WsServer.

v The WebSphere Application Server was started as a service (on Windows2000), or as a service or from the command line (Windows 2003 orWindows 2008).

If none of the preceding items appear to be the cause, check the system logand the WebSphere Application Server start logs for error messages.

Discovery of WebSphere Application Server is not logged

ProblemThe discovery of the WebSphere Application Server is not logged in theDiscoverManager.log file. Because a local anchor is used for the discovery,the log messages are placed in to a separate file.

SolutionThe log messages are placed in the following log files, where hostname isthe fully qualified domain name of the TADDM server:v local-anchor*.hostname.WebSphereAgent.log

v local-anchor*.hostname.WebSphereNodeSensor.log

Errors when security is enabled on WebSphere ApplicationServer

ProblemThe following types of error messages are displayed:v ERROR cdb.WebSphereAgentDelegate - [WebSphereAgentDelegate.E.1]

discover() failed with exception : java.lang.Exception:Unable to connect to the WebSphere server at


http://www.ibm.com/software/tivoli/opal

9.48.158.37:8,880 - ADMC0016E:The system cannot create a SOAP connectorto connect to host 9.48.158.37 at port 8880...

v ERROR cdb.WebSphereJMXUtils - An error occurred,unable to establish a repository connectionusing the credentials raleigh-was60:com.ibm.websphere.management.exception.AdminException:javax.management.JMRuntimeException: ADMN0022E:Access is denied for the getServerConfig operation onFileTransferServer MBean because of insufficientor empty credentials.

These errors can occur for any of the following reasons:v No credentials exist in the access list for the WebSphere Application

Server.v In the credentials for the WebSphere Application Server, the certificates

are not correct or have not been entered through the access list.v In the credentials for the WebSphere Application Server, the password is

incorrect.

SolutionAdd the credentials in the access list for the WebSphere Application Server.Correct the certificates, enter the certificates through the access list, orprovide the correct password.

Failure to make a JMX connection

ProblemThe following type of error occurs:Sensor failed in remote server:Unable to connect to WebSphere server at 10.0.1.69:8880 - ADMC0016E:Could not create SOAP Connector to connect to host 10.0.1.69 at port 8880

This type of error indicates the following problems:v A missing or incorrect certificate or an incorrect user ID and password.

The following example shows a sample root cause:[SOAPException: faultCode=SOAP-ENV:Client;msg=Error opening socket:javax.net.ssl.SSLHandshakeException: certificate expired;targetException=java.lang.IllegalArgumentException:Error opening socket:javax.net.ssl.SSLHandshakeException: certificate expired]

v A firewall that is preventing a connection to the WebSphere ApplicationServer through the SOAP port.

v The WebSphere Application Server might not be in a good state, eventhough the process shows up in the process table or Windows serviceslist. To test the state of the WebSphere Application Server, try to connectto it using the wsadmin WebSphere administrative utility. If thewsadmin utility fails, the sensor has problems also.

SolutionRun one of the following programs, which tests the JMX connection toverify credentials and connectivity:v For Linux, Solaris, AIX, and Linux on System z operating systems:

$COLLATION_HOME/bin/testwasconnection.sh. Instructions for runningthis program are in the testwasconnection.sh file.


v For Windows systems: %COLLATION_HOME%\bin\testwasconnection.bat.Instructions for running this program are in the testwasconnection.batfile.

Verify that the version of the WebSphere Application Server, that the sensoris to discover matches the version of the WebSphere Application ServerJAR files on the TADDM server. If a class is missing, ensure that thecorrect JAR files are in the correct location.

Sensor fails on a JMX query

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

This error indicates 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

SolutionCheck the logs to see what is being queried and whether that value isreadable in the WebSphere Application Server console. This error usuallyoccurs because discovery is run overnight, and WebSphere ApplicationServers are down for maintenance reasons. In this case, restart the server,and try the discovery again.

Data store error - schema not updated

ProblemThe schema was not updated accurately for the version of TADDM that isinstalled.

SolutionDrop and re-create the database.

Data store error - duplicate objects

ProblemThe amount of sensor data that is stored is too large and is causingduplicate objects to be stored. To see this error, the logging level must beset to DEBUG.

SolutionIdentify the model object that the topology manager had difficulty instoring. The problem might be that too many objects are being stored inthe same table for the database. Consult IBM Software Support to resolvethis issue.

Data store error - value too large to fit

ProblemA value cannot be stored because it exceeds the maximum valid length fora column in the database. The error message is in the TopologyManager.logfile, but to see this error, the logging level must be set to DEBUG.

SolutionLook for database exceptions complaining about the value being too largeto fit into the column. Determine the table and column that contains theproblem, update the schema, and re-create the database.


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

ProblemStorage of data collected from a WebSphere discovery is taking too long.

SolutionThe database tuning script was not run before TADDM schema creation.Before creating the TADDM schema, run the following database tuningscript:v For non-Windows systems:

$COLLATION_HOME/bin/gen_db_stats.jy

v For Windows systems:%COLLATION_HOME%\bin\gen_db_stats.bat

WebSphere Application Server is down

ProblemThe WebSphere Application Server is down for one of the followingreasons:v TADDM runs when a WebSphere Application Server is in maintenance,

and a discovery does not complete. The local-anchor*.hostname.WebSphereAgent.log file or local-anchor*.hostname.WebSphereNodeSensor.log file might display thefollowing error message:INFO cdb.AnchorServer[main] - [AnchorServer.I.0] server no longeraccepting new connections

v An error message states that the query cannot be completed.

SolutionVerify that the WebSphere Application Server is functioning properly.

Web services cannot be discovered

ProblemWeb services cannot be discovered.

SolutionTADDM can discover Web services only for the Version 6 releases ofWebSphere Application Server.

To discover Web services for a Version 6 release of WebSphere ApplicationServer, you must set the deepDiscoveryLevel property to true in the sensorconfiguration as part of the Discovery Profiles.

Sensor does not show as much data as it did in previousreleases of TADDM

ProblemThe Details window for WebSphere cells, nodes, and servers does not showas much detail as it did in previous TADDM releases, and many of thetabs in the window have no data.

SolutionTADDM implements the following discovery levels:v Shallowv Mediumv Deep


The default discovery level for the WebSphere Application Server sensor isshallow.

To obtain more detail about the WebSphere Application Server, create adiscovery sensor configuration for the WebSphereCellSensor sensor, and inthe Sensor Configuration window. Set the value of themediumDiscoveryLevel property or the deepDiscoveryLevel property totrue.

WebSphere sensor fails during WebSphere discovery on an AIXoperating system due to problems with the AIX ps command

ProblemOn some AIX operating systems, running the UNIX ps command returnstruncated Java CLASSPATH strings. The strings are not recognized by theTADDM WebSphere sensor, resulting in a failed discovery.

SolutionUpgrade to at least the AIX 5.3. FP5 (5.3.0.50) version. This version andlater versions of AIX return the full Java CLASSPATH strings.

Message CTJDT0736W is shown

ProblemInsufficient credentials exist in the access list for the Secure Shell (SSH)protocol or Windows Management Instrumentation (WMI) on the hostsystem where the distributed node is running.

The computer system credentials for this host system are used to retrieveinformation to populate the host for the node and server configurationitems on that system.

SolutionIf you want this information to be populated, you must add theappropriate computer system credentials for the host system.

WebSphere sensor fails and the following message is displayed:CTJTD0692E

ProblemWhile attempting discovery of a WebSphere Deployment Manager (Version6.1), the WebSphere sensor fails with the following message:CTJTD0692E The distributed cell deployment manager bind address is notfound for the following cell:etabsap1TCell

SolutionDiscoveries involving the sensors related to WebSphere DeploymentManager must have a working DNS. As a workaround, changecom.collation.platform.os.disableRemoteHostDNSLookups to true, andensure that the TADDM server always has the correct DNS search path.

WebSphere sensor fails and the following message is displayed:CTJTD3021E

ProblemThe WebSphere sensor fails with the following message:CTJTD3021E The sensor fails in a remote server :CTJTD2120E An error has occurred in the discovery process.:CTJTD0775E A connection to the WebSphere server is not


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

SolutionVerify that the problem is with the SSL support in the WebSphere clientcode. To verify, ensure that the WebSphere access list entry for thisWebSphere Server is first in the access list (before any other WebSpherecredentials). If the discovery is successful, import all the WebSpherecertificates from the different servers into one truststore. Having multipleaccess list entries with different user IDs and passwords is acceptable.However, all the access list entries must specify the same truststore, whichcontains all the certificates.

For additional information, see “Configuring the access list” on page 51.

WebSphere JDBC driver sensor does not start

ProblemThe WebSphere JDBC driver sensor does not start.

SolutionTo establish why the WebSphere JDBC driver sensor does not start, ensurethat the following conditions have been met:v A user profile for Level 3 discovery has been created and the WebSphere

JDBC driver sensor is enabled.v Deep discovery is enabled for the WebSphere cell sensor.

WebSphere JDBC driver sensor cannot connect to the targethost and the following message is displayed: CTJTD0796E

ProblemDuring the discovery, the WebSphere JDBC driver sensor cannot establish aconnection with target host and the CTJTD0796E error message isdisplayed.

SolutionThe following situations are possible reasons for this error:v SSH connection could not be established with the host.v A connection with the host was established, but the user did not have

the appropriate privileges to run the WebSphere setupCmdLine script.v A connection with the host was established, but the user did not have

the appropriate privileges to run the Java command.

You must check the sensor logs files to determine which of these situationshas occurred.

If the sensor fails and the warning CTJTD0798W is displayed in the logfiles, ensure that the user specified in the WebSphere SSH access list entryhas the appropriate privileges to run the WebSphere setupCmdLine script.

If the sensor fails and the warning CTJTD0799W is displayed in the logfiles, ensure that the user specified in the WebSphere SSH access list entryhas the appropriate privileges to run the Java command.


IBM WebSphere eXtreme Scale cache sensorThe IBM WebSphere eXtreme Scale cache sensor discovers IBM WebSphereeXtreme Scale caches and some of their components.

The sensor discovers the following elements for the eXtreme Scale cache:v The name of the cachev A list of nodes on which the cache resides

The sensor discovers the following elements for each eXtreme Scale node:v The name of the nodev The host name of the nodev The contents of the main configuration filev The contents of the orb.properties configuration file for the JVM that runs this

node and version of this JVMv The contents of .xml, .sh, .props, and .properties files that are in the same

directory as main configuration file


WebSphereXSCacheSensor

Prerequisites

IBM WebSphere eXtreme Scale must be running on the target computers.

The path to the configuration file, specified by the -objectgridfile parameter,must be absolute.

Security issues

The user must have permission to perform the following tasks:v Get the complete list of processes, including Java virtual machine (JVM)

processes, running on the target system.v Read the configuration file specified by the -objectgridfile parameter, typically

objectGrid.xml.v Read any XML files, script files or properties files in the same directory as the

configuration file specified by the -objectgridfile parameter, if this informationis to be captured.

v Run the JVM that runs the eXtreme Scale node with the -version parameter, toget runtime environment version information.

v Read the orb.properties configuration file, which is in the lib directory of theJVM.

Limitations

The following limitations apply:v Only those eXtreme Scale nodes that are using separate JVMs as containers for

eXtreme Scale caches are discovered. Caches that use special web applications ascontainers for eXtreme Scale nodes are not discovered.

v JVMs that provide catalog services for eXtreme Scale nodes are not discovered.


v If more than one JVM process is started with the same node name and the samecopy of the configuration file specified by the -objectgridfile parameter, thesensor does not recognize that they are separate nodes, and the nodes aremerged.

v The sensor looks for configuration files only in the same directory as theconfiguration file specified by the -objectgridfile parameter, and itssubdirectories. Only files with one of the following extensions are recognized:– .xml

– .sh

– .props

– .properties

You cannot configure the file extension recognized.v The sensor does not parse the configuration files, but captures the entire

contents of each file.v When checking the -objectgridfile parameter, the sensor ignores case.

Model objects with associated attributesThe IBM WebSphere eXtreme Scale cache sensor creates model objects withassociated attributes. The attributes indicate the type of information that the sensorcollects about configuration items in the IBM WebSphere environment.


app.JVMExecutableName

JVMVersion

Publisher

SoftwareVersion

websphere.WebSphereXSCache

v Name

websphere.WebSphereXSCacheNode

v Namev Host



use for authentication to the target computer system.

IBM WebSphere Message Broker sensorThe IBM WebSphere Message Broker sensor discovers WebSphere Message Brokerattribution at broker instance, configuration, and application levels for Windowsand UNIX.



MBServerSensor

Prerequisites

The TADDM server requires the following login information:

System login with ability to discover the target computer.

You must be authorized to run mqsiprofile command.


The sensor creates the following model objects:v messaging.mb.MBBrokerv messaging.mq.MQQueueManagerv messaging.mb.MBExecutionGroupv messaging.mb.MBHTTPListenerPropertiesv messaging.mb.MBHTTPConnectorPropertyv messaging.mb.MBHTTPSConnectorPropertyv messaging.mb.MBHTTPListenerPropertyv messaging.mb.MBBrokerSecurityv messaging.mb.MBBrokerProfilev messaging.mb.MBMessageFlowv messaging.mb.MBMessageFlowNodev messaging.mb.MBBarFilev messaging.mb.MBProperty


Configuring the discovery profileIf you want to change the discovery level, update the discovery profile for the IBMWebSphere Message Broker sensor.

To change the default the discovery level for this sensor, complete the followingsteps:1. In the Discovery Profiles window, click New.2. In the Create New Profile window, type the profile name, description, and click

OK.3. In the list of sensors, click the MBServerSensor, and click New.4. In the Create Configuration window, type the name and description for your

configuration of the MBServerSensor.5. In the Configuration section of the Create Configuration window, to change the

discovery options, select one of the following choices:v To use OS credentials to conduct discovery, double-click the value for

useHostAuth and change from false to true

v To discover WebSphere message flow nodes attributes, double-click the valuefor useNodeLevel and change from false to true


6. Click OK to return to the Discovery Profiles window.7. In the Discovery Profiles window, click Save.8. Choose this discovery profile when running a discovery.

For more information about Discovery Profiles, see the “Using” topics in the IBMTivoli Application Dependency Discovery Manager information center.

Configuring the access listThis topic describes the access details you require to configure the access list.

To configure the access list, complete the following steps:1. Select Messaging Servers as the Component Type.2. Select WebSphere Message Broker as the Vendor.3. Specify the following required information:

v User namev Password

You must be authorized to run mqsiprofile command.



com.collation.platform.os.UnixOs.forcedServerList=bipbrokerThis property forces the bipbroker process to start the sensor on UNIXplatform.

com.collation.platform.os.WindowsOs.forcedServerList=bipserviceThis property forces the bipservice process to start the sensor on Windowsplatform.

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


ProblemThe WebSphere Message Broker sensor does not start.

SolutionMake sure that the bipbroker process name is added to thecom.collation.platform.os.UnixOs.forcedServerList property in thecollation.properties file.

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


MQServerSensor


Security issues

The TADDM server requires the following login information:v System login with ability to discover the target computer.v For the WebSphere MQ server on a UNIX system, the WebSphere MQ user login

and password used to log on to the MQSC console.


The sensor creates the following model objects:v app.messaging.mq.MQChannelv app.messaging.mq.MQClientConnectionChannelv app.messaging.mq.MQClusterv app.messaging.mq.MQClusterReceiverChannelv app.messaging.mq.MQClusterSenderChannelv app.messaging.mq.MQInstallationv app.messaging.mq.MQListenerv app.messaging.mq.MQNameListv app.messaging.mq.MQTCPListenerv app.messaging.mq.MQQueueManagerv app.messaging.mq.MQRequesterChannelv app.messaging.mq.MQServerChannelv app.messaging.mq.MQTCPListenerv app.ProcessPool

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







Limitations

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




The sensor supports application descriptors. Create the appdescriptors directorywith appdescriptors files inside the WebSphere MQ Queue Manager datadirectory. For example, in a Linux environment, this directory is/var/mqm/qmgrs/test5/appdescriptors. The test5 directory is a Queue Managername. Read access to that directory must be granted for the mqm user that is usedto discover that manager.


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

Ensure that the WebSphere MQ user you add to the access list has privileges torun the runmqsc command.



com.collation.platform.os.UnixOs.forcedServerList=amqzxma0This property forces the aqmzxma0 process to start the sensor.

com.collation.topobuilder.mq.clusterrelations=trueThis property enables the building of dependencies based on clustermembership. Every Queue Manager in the cluster has two dependencies(one as a source and one as a target) to every other Queue Manager in thesame cluster.

If not set, the default value is false.

com.collation.topobuilder.mq.channelrelations=trueThis property enables the building of dependencies based onsender-receiver channel names. If not set, the default value is false.

Limitation: This capability is available only if the channel names containboth the name of the source manager and the target manager. Otherwise, itis not possible to build a regular expression for thecom.collation.topobuilder.mq.channelnaming property.

com.collation.topobuilder.mq.checkreceiverchannelname=trueIf set to true, the dependency is set only if there is a receiver channel witha name matching the sender channel name on the target manager. Thedefault value is false.

com.collation.topobuilder.mq.channelnaming=<REGULAR EXPRESSION>Allows you to specify custom channel naming rules for creating channeldependencies. REGULAR_EXPRESSION must return two named groups:v The first matches the source manager name.


v The second matches the target queue manager name.

If the custom channel naming does not contain the source queue managername, for example, TO.TARGET_MANAGER, the first group can be set toan empty value, for instance, ()TO.(.*). The source queue manager name isnot compared with the sender channel parent queue manager name in thatcase.

If not set, the default value for the <REGULAR_EXPRESSION) isCH\\.(.*?)\\.TO\\.(.*

The following properties are used for generating display names for theQueueManager.

com.collation.discover.agent.MQQueueManager.Use ListenningIp=trueSets the QueueManager name; the default value is false.

<FQDN>:<QUEUE_MANAGER_NAME> - First non-empty Fully QualifiedDomain Name (FQDN) or IP from the first listening MQListener is used

com.collation.discover.agent.MQQueueManager.UseIpFromConnections=trueThe default value is false.

<FQDN>:<QUEUE_MANAGER_NAME> - First non-empty FQDN (or IP)taken from LOCLADDR attribute of the ServerConnection is used.

com.collation.discover.agent.MQQueueManager.UseEmptyHostName=trueIf the FQDN is not present, the first non-empty FQDN (or IP) taken fromthe LOCLADDR attribute of the ClientConnection is used. The defaultvalue is false.

<QUEUE_MANAGER_NAME> - The QueueManager name without theFQDN is used.

com.collation.topobuilder.mq.removerelationsIf not set, the default value is false. If set to true, dependencies for theWebSphere MQ queue manager are removed if the state is other thanrunning.

If none of the preceding properties are set to true (UseListenningIp orUseIpFromConnections did not resolve the FQDN)

<HOST_FQDN>:<QUEUE_MANAGER_NAME> - The parent host FDQN is used

The following properties are used to specify that the sensor should use the sudocommand when running MQ commands on the server.

com.collation.discover.agent.MqServerAgent.versionCommand=sudo -u userSpecifies that the sensor should use sudo with the specified user namewhen running the MQ version command.

com.collation.discover.agent.MqServerAgent.statusCommand=sudo -u userSpecifies that the sensor should use sudo with the specified user namewhen running the MQ dspmq command.

com.collation.discover.agent.MqServerAgent.mqscCommand=sudo -u userSpecifies that the sensor should use sudo with the specified user namewhen running the MQ runmqsc command.

Each of the preceding properties can be scoped to a particular operating systemtype, IP address, or both, as in the following example:com.collation.discover.agent.MqServerAgent.mqscCommand.Linux.1.2.3.4=sudo -u mqm


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


ProblemThe WebSphere MQ Server sensor does not start.

SolutionEnsure that the amqzxma0 process name is added to thecom.collation.platform.os.UnixOs.forcedServerList property in thecollation.properties file.

iPlanet server sensorThe iPlanet server sensor discovers iPlanet Web servers.


IPlanetServerSensor

Prerequisites

The TADDM service account should have:v Execute permissions on the iPlant binary, either ns-httpd or webserd.v Read access to the iPlanet configuration files


The sensor creates the following model objects:v app.AppConfigv app.SoftwareContainerv app.SoftwareModulev app.StaticContentModulev app.web.CGIScriptv app.web.iplanet.IPlanetJSPv app.web.iplanet.IPlanetJVMSettingsv app.web.iplanet.NSAPIPluginv app.web.iplanet.IPlanetServerv app.web.iplanet.IPlanetServletv app.web.iplanet.IPlanetSSLSettingsv app.web.iplanet.IPlanetVirtualHostv app.web.iplanet.IPlanetWebContainerv app.web.iplanet.WebLogicConnectionv app.web.WebConnectionv sys.DataFile sys.Directory

JBoss server sensorThe JBoss server sensor discovers JBoss Application Server servers.



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.


The sensor creates the following model objects:v app.AppServerv app.j2ee.J2EEServerv app.j2ee.jboss.JBossClusterv app.j2ee.jboss.JBossDomainv app.j2ee.jboss.JBossJMSServerv app.j2ee.jboss.JBossServer


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 sensorThis topic describes common problems that occur with the JBoss server sensor andpresents solutions for those problems.

JBoss4xServerSensor does not launch

ProblemThe JBoss4xServerSensor does not launch.

SolutionCheck 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

ProblemYou see the message “JBoss libraries not found” while running the sensor.


SolutionEnsure that the JBoss JAR files for the JBoss server version you are runningare present in the dist directory with read access for the TADDM serveruser.

LDAP sensorThe LDAP sensor discovers LDAP servers.


LdapSensor

Limitations

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


The sensor creates the model object sys.LDAPSAP.


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 sensorThis topic describes common problems that occur with the LDAP sensor andpresents solutions for those problems.

Error occurs during a discovery

ProblemThe sensor discovery finishes with the following error message:CTJTD0421E The LDAP server contains the following unexpected attributes:javax.naming.AuthenticationNotSupportedException: [LDAP: error code 13 - confidentiality required]

SolutionThe LADP server requires encryption. The LADP sensor cannot carry out adiscovery if the LADP server requires encryption, disable the encryptionon the LADP server.

Sensor cannot display all attribute information

ProblemThe following attribute information is not displayed after running adiscovery: LDAP Version, Threads, and Total Connections.

SolutionEnable the LDAP application monitor to discover LDAP Version, Threads,and Total Connections.


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


MSClusterSensor

Prerequisites

The MS Cluster sensor requires:v Successful discovery of Windows computer systemsv The Cluster Server ClusSvc service, must be runningv Using the TADDM Windows Management Instrumentation (WMI) provider,

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

Limitations

The scope of discovery must contain the IP address of at least one of the MSCluster nodes or mention the cluster IP address. A node is any computer that ispart of the cluster.

Model objects with associated attributesThe MS Cluster sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about MicrosoftServer clusters in your IT environment.


app.MsFailoverCluster.MsCluster

v CrossSubnetDelayv CrossSubnetThresholdv DefaultNetworkRolev Descriptionv DisableGroupPreferredOwnerRandomizationv Domainv EnableEventLogReplicationv HangRecoveryActionv HangTimeoutv InternalNetworkv LogLevelv LogSizev MaintenanceFilev MaxNumberofNodesv MaxQuorumArbitrationTime


v MinQuorumArbitrationTimev Namev Nodesv PlumbAllCrossSubnetRoutesv PublicNetworksv QuorumLogFileSizev QuorumPathv QuorumTypev RegroupOpeningTimeoutv RegroupPruningTimeoutv RegroupStageTimeoutv RegroupTickv RequestReplyTimeoutv ResourceDllDeadlockPeriodv ResourceGroupsv Resourcesv SameSubnetDelayv SameSubnetThresholdv SecurityLevelv WitnessDatabaseWriteTimeoutv WitnessRestartInterval

app.MsFailoverCluster.MsClusterNode

v Descriptionv EnableEventLogReplicationv InitialLoadInfov LastLoadInfov Namev NodeHighestVersionv NodeLowestVersionv System

app.MsFailoverCluster.MsClusterResource

v AppServersv CryptoCheckpointsv DeadlockTimeoutv DebugPrefixv DeleteRequiresAllNodesv DependsOnResourcesv Descriptionv HasSeparateMonitorv IpAddressesv IsAlivePollIntervalv IsCoreResourcev IsLocalQuorumCapablev IsPersistentState


v IsQuorumCapablev LooksAlivePollIntervalv Namev PendingTimeoutv RegistryCheckpointsv RestartActionv RestartDelayv RestartPeriodv RestartThresholdv RetryPeriodOnFailurev Type

app.MsFailoverCluster.MsClusterResourceGroup

v AntiAffinityClassNamesv AutoFailbackTypev Descriptionv FailbackWindowEndv FailbackWindowStartv FailoverPeriodv FailoverThresholdv IsPersistentStatev Namev Parentv Resources


A domain level account that is a member of the administrators group is required.To configure the access list, complete the following steps:1. Select ComputerSystem (Windows) as the Component Type.2. Specify the access information (user name and password).

An account with administrator privileges must be used.

Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft Clustersensor and presents solutions for those problems.

WMI service crashes

ProblemWMI service crashes on target during discovery.

SolutionEnsure that all WMI-related fixes, including fix KB933061, are applied onthe target system. If problems persist, use the following Microsoft utilitiesto troubleshoot WMI problems:


WMIDiagThe WMIDiag utility is available at the following Web site:http://www.microsoft.com/downloads/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en

Follow the instructions to install and run the utility, and verify thatWMI is working correctly.

Microsoft Exchange Server sensorThe Microsoft Exchange Server sensor discovers Microsoft Exchange Server.


ExchangeServerSensor

Prerequisites

The account TADDM uses to access the windows gateway must have an ActiveDirectory account and not a local account on the gateway.

Limitations

Note the following limitations:v In an Exchange Server clustering environment, the sensor discovers only the

active cluster node.v The sensor discovers the virtual servers for only the SMTP and X400 protocols.


The sensor creates the following model objects:v app.messaging.exchange.ExchangeAdministrativeGroupv app.messaging.exchange.ExchangeConnectorv app.messaging.exchange.ExchangeDSAccessDomainControllerv app.messaging.exchange.ExchangeFolderTreev app.messaging.exchange.ExchangeLinkv app.messaging.exchange.ExchangeMailboxv app.messaging.exchange.ExchangeMailboxStorev app.messaging.exchange.ExchangeProtocolVirtualServerv app.messaging.exchange.ExchangePublicFolderv app.messaging.exchange.ExchangePublicFolderStorev app.messaging.exchange.ExchangeQueuev app.messaging.exchange.ExchangeRoutingGroupv app.messaging.exchange.ExchangeScheduleIntervalv app.messaging.exchange.ExchangeServerv app.messaging.exchange.ExchangeStorageGroup



http://www.microsoft.com/downloads/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en




To configure the access list, complete the following steps:1. Select Messaging servers as the Component Type.2. Select Microsoft Exchange Server for the Vendor.3. Specify the following required information:

a. User nameb. Password

The sensor uses credentials from the access list in the following sequence:1. The sensor attempts to connect to the Microsoft Exchange Server, using

Microsoft Exchange Server user credentials from the access list.2. If step 1 fails, the sensor attempts to connect to Microsoft Exchange Server

using the Computer System (Windows) user credentials from the access list.


com.collation.discover.agent.exchange.command.timeout=600000

The default value is 600000 (in milliseconds), which is 10 minutes. Thevalue must be an integer.

This property specifies the timeout (in milliseconds) for the WMI call to getthe Exchange Server information.

If the WMI call takes a long time (which might occur in largeenvironments), you can increase this value.

Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft ExchangeServer sensor and presents solutions for those problems.

Sensor is not started

ProblemThe Exchange Server sensor is not started.

SolutionFor Microsoft Exchange Server 2003, ensure that the Microsoft ExchangeManagement service is started on the target Windows system. Run theservices.msc program to check the status of the service.

Discovery does not find any systems

ProblemThe Exchange Server sensor completes successfully with the followingmessage: “There was nothing to be discovered.”

SolutionNo active Exchange Server is running on the target computer system. Thefollowing lists the possible causes:v The Exchange Management Tool is installed, but the Exchange Server is

not installed. For Microsoft Exchange Server 2003, ensure the followingthings are done:


1. Start the Exchange System Manager on the computer where theExchange Server is installed.

2. In the list of servers, verify that the local Exchange Server isdisplayed.

3. If the local Exchange Server is not displayed, verify that theMicrosoft Exchange Server is installed and running correctly.

v The Exchange Server is installed as a cluster node, but it is currentlyinactive. For Microsoft Exchange Server 2003, complete the followingsteps:1. Start the cluster administration program on the computer where the

Exchange Server is installed as a cluster node.2. Check which Exchange resource is assigned to the Exchange virtual

server.

Sensor cannot retrieve server information

ProblemThe Exchange Server sensor terminates with the following error message:CTDTD0811E The Exchange Server Agent is unable to retrieveinformation from the Microsoft Exchange Server

SolutionThis error message means that no output was retrieved through theWindows Management Instrumentation (WMI). For Microsoft ExchangeServer 2003, complete the following steps:1. Run the services.msc program on the target Windows system.2. Restart the Microsoft Exchange Management service.3. Run the discovery again.4. If the problem persists, see the sensors/ ExchangeServerSensor-*.log

file to determine if the problem is WMI related.

Microsoft Exchange Server 2007, 2000, and 5.5 are notdiscovered

ProblemThe Exchange Server sensor terminates with the following error message:CTDTD0812E No Microsoft Exchange Server is found.

SolutionThis error message means that no Exchange Server object exists in theoutput that was retrieved through the Windows ManagementInstrumentation (WMI). For Microsoft Exchange Server 2003, complete thefollowing steps:1. Run the services.msc program on the target Windows system.2. Restart the Microsoft Exchange Management service.3. Run the discovery again.4. If the problem still persists, see the sensors/ ExchangeServerSensor-

*.log file to determine if the problem is WMI related.

Sensor cannot access Windows Management Instrumentation(WMI) namespace

ProblemThe following message is in the sensors/ExchangeServerSensor-*.log file:System.UnauthorizedAccessException: Access denied


SolutionThe message typically means that the TADDM service account does nothave the appropriate permission to access the required WMI namespace.For Microsoft Exchange Server 2003, complete the following steps:1. Ensure that the TADDM service account has full permission for the

following WMI namespaces:Root\CIMV2Root\CIMV2\Applications\ExchangeRoot\MicrosoftExchangeV2

To configure the permission, complete the following steps:a. Click Start > Run > Open wmimgmt.msc.b. Right-click WMI Control (Local), and click Properties.c. In the WMI Control (Local) Properties window, click the Security

tab.d. Click WMI namespace, and click Security.e. In the Security window, select the following permissions to allow

the user or group:v Execute Methods

v Full Write

v Partial Write

v Provider Write

v Enable Account

v Remote Enable

v Read Security

v Edit Security

2. Ensure that the TADDM service account has enough permission for theExchange Server and Folder Tree objects. To configure the permission,complete the following steps:a. Click Start > All Programs > Microsoft Exchange > System

Manager

b. In the Exchange System Manager, expand Servers tree and find theserver object to be discovered.

c. Right-click the server and select Properties.d. In the Properties window, click the Security tab.e. Click Add, and select the user for the TADDM service account, and

click OK.f. In the Permissions for Administrator field, make sure Allow check

boxes next to the following permissions is turned on:v Read

v Execute

v Read permissions

v List contents

v Read properties

v List object

v View information store status

g. In the Exchange System Manager, expand Folders tree and find thefolder tree object to be discovered.

h. Do the same operation as described above for the server.


WMI class does not exist

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

SolutionThe message typically means that the sensor tried to refer to a WMI classthat does not exist. Possible causes include that the Exchange Server is notinstalled correctly, or the version of Exchange Server is not supported.

Only Microsoft Exchange Server 2003 is supported. Microsoft ExchangeServer 2007, 2000, and 5.5 are not discovered because these versions are notsupported.

Unexpected discovery result

ProblemThe virtual servers for the following protocols are not discovered:v HTTPv IMAP4v NNTPv POP3

SolutionFor Microsoft Exchange Server 2003, the sensor supports virtual servers foronly SMTP and X400 protocols.

Microsoft Exchange 2007 Server sensorThe Microsoft Exchange 2007 Server sensor discovers Microsoft Exchange 2007Server.


Exchange2007Sensor

Prerequisites

The Exchange management tools and the Window PowerShell must be installed onthe Exchange Server.

To verify that the user account permissions are correct, run the following commandon 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 activemailbox server.

Model objects with associated attributesThe Exchange 2007 server sensor creates model objects with associated attributes.The attributes indicate the type of information that the sensor collects aboutMicrosoft Exchange 2007 Servers resources in your IT environment.



app.messaging.exchange.AcceptedDomain

v AcceptedDomainNamev Defaultv DistinguishedNamev DomainNamev DomainType

app.messaging.exchange.ActiveSyncVirtualDirectory

v BasicAuthenticationEnabledv ClientCertEnabledv RemoteDocumentsActionForUnknownServersv WebSiteNamev WebSiteSSLEnabled

app.messaging.exchange.ClientAccess

v ClientAuthenticationMethodv ExternalHostNamev OutlookAnywhereEnabledv SSLOffloading

app.messaging.exchange.TransportServer

v AntispamUpdatesEnabledv ConnectivityLogEnabledv ConnectivityLogPathv DelayNotificationTimeoutv ExternalDNSAdapterEnabledv InternalDNSAdapterEnabledv MaxOutboundConnectionsv MaxPerDomainOutboundConnectionsv MessageExpirationTimeoutv MessageTrackingLogEnabledv MessageTrackingLogPathv OutboundConnectionFailureRetryIntervalv ReceiveProtocolLogPathv SendProtocolLogPathv TransientFailureRetryCountv TransientFailureRetryInterval

app.messaging.exchange.ExchangeConnector

v Enabledv Fqdnv ProtocolLoggingLevel

app.messaging.exchange.ExchangeJournalRule

v EmailAddressv JournalRuleIdentityv Recipient


v ReportNDRTov Scope

app.messaging.exchange.ExchangeMailbox

v Aliasv Mailboxv DisplayNamev OrganizationalUnitv PrimarySmtpAddressv RecipientTypeDetailsv UserDistinguishedName

app.messaging.exchange.ExchangeMailboxStore

v AllowFileRestorev CopyEdbFilePathv DeletedItemRetentionv IssueWarningQuotav JournalRecipientv LastFullBackupv LastIncrementalBackupv MailboxRetentionv MountAtStartupv ProhibitSendQuotav ProhibitSendReceiveQuotav RetainDeletedItemsUntilBackup

app.messaging.exchange.ExchangeProtocol

v AuthenticatedConnectionTimeoutv Bannerv DistinguishedNamev LoginTypev MaxCommandSizev MaxConnectionsv MaxConnectionsFromSingleIPv MaxConnectionsPerUserv PreAuthenticatedConnectionTimeoutv ProtocolNamev ProxyTargetPortv UnencryptedOrTLSBindingsv X509CertificateName

app.messaging.exchange.ExchangePublicFolder

v AgeLimitv UseDatabaseQuotaDefaultsv UseDatabaseReplicationSchedule

app.messaging.exchange.ExchangePublicFolderStore

v AllowFileRestorev CopyEdbFilePath


v CustomReferralServerListv DeletedItemRetentionv IssueWarningQuotav ItemRetentionPeriodv LastFullBackupv LastIncrementalBackupv MaxItemSizev MountAtStartupv ProhibitPostQuotav PublicFolderHierarchyv ReplicationMessageSizev ReplicationPeriodv RetainDeletedItemsUntilBackupv UseCustomReferralList

app.messaging.exchange.ExchangeServer

v ActiveDirectoryDomainNamev DistinguishedNamev Domainv Editionv ErrorReportingEnabledv ProductIDv Site

app.messaging.exchange.ExchangeServerRole

v RoleName

app.messaging.exchange.ExchangeVirtualDirectory

v DistinguishedNamev ExternalURLv InternalURLv Pathv VirtualDirectoryName

app.messaging.exchange.MailboxServer

v AutoDatabaseMountDialv ForcedDatabaseMountAfterv RedundantMachines

app.messaging.exchange.OABVirtualDirectory

v PollInterval

app.messaging.exchange.OwaVirtualDirectory

v ActiveSyncIntegrationEnabledv AllAddressListsEnabledv BasicAuthenticationv CalendarEnabledv ChangePasswordEnabledv ContactsEnabledv DefaultDomain


v DigestAuthenticationv FormsAuthenticationv JournalEnabledv JunkEmailEnabledv LogonFormatv NotesEnabledv OwaVersionv PremiumClientEnabledv PublicFoldersEnabledv RecoverDeletedItemsEnabledv RemindersAndNotificationsEnabledv RulesEnabledv SMimeEnabledv SearchFoldersEnabledv SignaturesEnabledv SpellCheckerEnabledv TasksEnabledv ThemeSelectionEnabledv UMIntegrationEnabledv WebSiteNamev WindowsAuthentication

app.messaging.exchange.ReceiveConnector

v AnonymousUsersPermissionv BasicAuthRequiresTLSv BasicAuthenticationv ExchangeAuthenticationv ExchangeLegacyServersPermissionv ExchangeServersPermissionv ExchangeUsersPermissionv ExternalAuthoritativev MutualAuthTLSv PartnersPermissionv RemoteIPRangesv TLSv WindowsAuthentication

app.messaging.exchange.SendConnector

v AddressSpacesv DNSRoutingEnabledv DomainSecureEnabledv IsScopedv SmartHostsv UseExternalDNSRoutersEnabled

app.messaging.exchange.TransportRule

v Comments


v Enabledv RulePriorityv TransportRuleName



The sensor requires the credentials (user name and password) for the computersystem on which the Exchange server is running ComputerSystem (Windows).

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

use to access the Active Directory domain on which the Exchange server isrunning. The user must be a member of the local administrators group, andmust be assigned Exchange View Only Administrator permissions on theExchange 2007 Server.

3. Specify the access information (user name and password) that TADDM mustuse to access the Edge Transport server role. The Edge Transport server role ishosted on a dedicated computer and requires separate access information.


collation.properties file entries


com.collation.discover.agent.exchange.command.timeout= 600000

The timeout (in milliseconds) for the WMI call to get the Exchange Serverinformation. The default is 600000 milliseconds. Increase this value, whenthe WMI call takes a long time in large Exchange Server environments.

Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft Exchange2007 Server sensor and presents solutions for those problems.

The Exchange 2007 Server sensor does not start

ProblemThe Exchange 2007 Server sensor is not started.

SolutionFor Microsoft Exchange Server 2007, ensure that the following services arestarted:v Microsoft Exchange Information Store (store.exe)v Microsoft Exchange Service Host (Microsoft.Exchange.ServiceHost.exe)v Microsoft Exchange Transport (MSExchangeTransport.exe)v Microsoft Exchange Unified Messaging (umservice.exe)


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

Discovery returns a Stored-0 Exchange Server in the databasemessage

ProblemThe Exchange 2007 Server sensor completes successfully with the followingmessage: Stored-0 Exchange Server in the database.

SolutionNo active Exchange Server is running on the target computer system. Thepossible causes for no Exchange Server running are:v The Exchange Server is installed as a cluster node, but it is currently

inactive. For Microsoft Exchange Server 2007, start the clusteradministration program on the computer where the Exchange Server isinstalled as a cluster node. Then verify that the node is active.

v The Server is acting as a provisioning volume and is not hosting any ofthe server roles.

v Check the log file for the cause of the failure and verify that the gatewayis configured correctly.

Invalid domain credentials used

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

SolutionVerify that in the Access List configuration, that the access information(user name and password) is correct. Access permission to the ActiveDirectory domain on which the Exchange server is running, and not thelocal computer, must be granted.

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


Microsoft HyperV Sensor

Prerequisites

To discover the hypervisor and the virtualized guest systems, the hypervisor mustbe 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 runthe wmic command to query the Windows Management Instrumentation (WMI)interface.


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

Limitations

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

Model objects with associated attributesThe Microsoft HyperV sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about MicrosoftWindows 2008 based computers with Microsoft Hyper-V Role enabled in your ITenvironment.


sys.ComputerSystemThe following attribute is associated with the host running the Hyper-Vsoftware:v ChildSystem (host)

sys.ComputerSystemThe following attributes are associated with the discovered objects that arevirtualized on the host:v HostSystemv IsVMIDanLPARv Manufacturerv MemorySizev Modelv Namev NumCPUsv SerialNumberv SystemBoardUUIDv UUIDv Virtual

app.AppServer

v Hostv MajorVersionv ProductNamev VendorNamev VersionString



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 entryfor Computer System (Windows) to discover the computers running WindowsServer 2008 with Hyper-V.

Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft HyperVsensor and presents solutions for those problems.

HyperV sensor is not running

ProblemThe HyperV sensor is not running.

SolutionVerify that the WindowsComputerSystemSensor is enabled in thediscovery profile. Include in the scope one of the following options for thetarget Hyper-V host (parent partition):v Host namev Range (start and end IP addresses)v Subnet (IP address of the subnet mask)

Verify that the WindowsComputerSystemSensor discovery of the targethypervisor host (parent partition) completes successfully. If there is afailure during the WindowsComputerSystemSensor discovery, then theHyperV sensor cannot start. Resolve the problems encountered by theWindowsComputerSystemSensor.

Open the MicrosoftHyperVSensor-<ip_address>.log and search for:Microsoft HyperV sensor starting. Fix any errors reported.

Guest computer systems are not displayed

ProblemThe HyperV sensor ran, but where are the guests located in the DataManagement Portal after a discovery?

Solution

In the Discovered Components pane go to Inventory Summary >Computer Systems > Other Computer Systems, to find the Hyper-V guestsystems (child partitions).

Microsoft IIS Web server sensorThe Microsoft IIS Web server sensor discovers Microsoft Internet InformationServices (IIS) servers.


IISWebServiceSensor

Prerequisites

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


v The gateway must have the IIS Manager installed. This method ensures that theCOM classes are installed. These classes are required by the TaddmTool AdsiDumpand AdsiEnum commands.

v If IIS Manager is not present, install it using Add/Remove Programs in theWindows 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 mustbe 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 aredisplayed in the log file and a deep discovery does not occur.


The sensor creates the following model objects:v app.ProcessPoolv app.web.iis.IIsModulev app.web.iis.IIsParameterv app.web.iis.IIsWebServerv app.web.iis.IIsWebServicev app.web.iis.IIsWebVirtualDirv sys.RuntimeProcess


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

Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft IIS Webserver sensor and presents solutions for those problems.

No Web server information discovered

ProblemThe sensor does not discover any Web server information.

SolutionIf the Web server information is missing, check the logs to determine if theTaddmTool program AdsiDump and AdsiEnum commands succeeded orfailed.


Check whether the TaddmTool program QueryRegistry commandssucceeded. Two registry paths are queried.v HKLM\SOFTWARE\Microsoft\W3SVC

v HKLM\SYSTEM\CurrentControlSet\Services\W3SVC

The first key provides general software information for IIS and thesecond provides service-related information.

Web server is duplicated

ProblemDuring discovery, duplicate IIS Web servers are found. This problem canoccur when the IIS Web servers have been discovered with an earlierversion of TADDM. Earlier releases of TADDM used port 0 as the defaultlistening port. If the same servers are discovered using a different listeningport, these servers are duplicated and they cannot be automaticallymerged.

SolutionUse an SQL statement to identify duplicate IIS Web servers in the database.The following statement can be run on one line, on DB2 or Oracledatabases:selectcast(APPZ.contextip_x as VARCHAR(100)) as CONTEXT_IP, APPZ.guid_x as OLD_GUID,APPZ.displayname_x as OLD_DISPLAYNAME,APPN.guid_x as NEW_GUID, APPN.displayname_x as NEW_DISPLAYNAMEfromAPPSRVR APPZ INNER JOIN APPSRVR APPN ON APPZ.contextip_x = APPN.contextip_x ANDAPPZ.jdoclassx = APPN.jdoclassxwhereAPPZ.jdoclassx=’com.collation.topomgr.jdo.topology.app.web.iis.IIsWebServiceJdo’and APPZ.displayname_x like ’%:0’ and APPN.displayname_x not like ’%:0’

Use one of the following methods to remove the duplicates:v Merge the duplicates in the Data Management Portal.v Manually delete the old configuration items.

For more information about merging and deleting discovered configurationitems, see the "Discovery tasks" section in the TADDM User's Guide.

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


NFSServerSensor


The sensor creates the following model objects:v sys.NFSExportv sys.NFSSAPv sys.NFSServicev sys.ServiceAccessPoint

Oracle Application Server sensorThe Oracle Application Server sensor discovers Oracle Application Server servers.



OracleAppSensor and OracleAppOpmnSensor

Prerequisites

Note the following prerequisites:v Discovery of the computer system must succeed.v An Oracle Application Server account must be entered in the access list.v An account with admin privilege is required (read-only ID can work).v Oracle Application Server libraries must be made available on the TADDM

server.v Relative paths are relative to $COLLATION_HOME.v Requires two subdirectories:

– j2ee– opmn

These files can be copied or NFS mounted from an existing OracleApplication Server installation.

The required JAR files on the TADDM server are:– j2ee/home/lib/ejb.jar

– j2ee/home/lib/adminclient.jar

– j2ee/home/lib/javax77.jar

– j2ee/home/lib/jmxcluster.jar

– j2ee/home/lib/jmx_remote_api.jar

– j2ee/home/lib/jmxri.jar

– j2ee/home/oc4jclient.jar

– opmn/lib/argus.jar

– opmn/lib/ons.jar

– opmn/lib/opmnconfig.jar

– opmn/lib/optic.jar

– opmn/lib/repositorycheck.jar

v Specify the location of the files in the com.collation.oracleapp.root.dir entryin the collation.properties file.

v These files must have read privileges for the collation user.


The OracleAppAgent creates the following model objects:v app.AppConfigv app.ConfigFile.SoftwareContainerv app.j2ee.EJBv app.j2ee.EntityBeanv app.j2ee.J2EEComponentv app.j2ee.J2EEDeployedObjectv app.j2ee.J2EEModulev app.j2ee.J2EEResourcev app.j2ee.JSP


v app.j2ee.MessageDrivenBeanv app.j2ee.oracleapp.OracleAppClusterv app.j2ee.oracleapp.OracleAppConnectorModulev app.j2ee.oracleapp.OracleAppDomainv app.j2ee.oracleapp.OracleAppEJBModulev app.j2ee.oracleapp.OracleAppJ2EEApplicationv app.j2ee.oracleapp.OracleAppJ2EEServerv app.j2ee.oracleapp.OracleAppJ2EEWebSitev app.j2ee.oracleapp.OracleAppJDBCConnectionPoolv app.j2ee.oracleapp.OracleAppJDBCDataSourcev app.j2ee.oracleapp.OracleAppJDBCDriverv app.j2ee.oracleapp.OracleAppJMSDestinationv app.j2ee.oracleapp.OracleAppJMSServerv app.j2ee.oracleapp.OracleAppJSPContainerv app.j2ee.oracleapp.OracleAppJTAResourcev app.j2ee.oracleapp.OracleAppProcessManagerv app.j2ee.oracleapp.OracleAppResourceAdapterv app.j2ee.oracleapp.OracleAppServletv app.j2ee.oracleapp.OracleAppWebModulev app.j2ee.StatefulSessionBeanv app.j2ee.StatelessSessionBeanv core.LogicalContentv enums.StatusEnumv net.BindAddressv net.IpAddressv sys.ComputerSystem

The OracleAppOpmn creates the following model objects:v app.AppConfigv app.ConfigFilev app.j2ee.oracleapp.OracleAppClusterv app.j2ee.oracleapp.OracleAppProcessManagerv app.web.oracleapp.OracleAppHTTPServerv core.LogicalContentv enums.StatusEnumv net.BindAddressv net.IpAddressv sys.ComputerSystem




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


com.collation.oracleapp.root.dir=lib/oracleappThe default value is lib/oracleapp.

This property specifies the location of the Oracle Application Serverlibraries on the TADDM server.

You can specify an absolute or relative path for the directory location. Ifthe value for this property is a relative path directory, the relative path isappended to the $COLLATION_HOME path.

com.collation.platform.os.ignoreLoopbackProcesses=trueThe default value is true, which means that the processes that are listeningon loopback interfaces are ignored. Therefore, if a server is listening onlyon the loopback IP address (127.0.0.1), and not on any other externallyavailable IP address, that server will not be discovered.

This property controls the discovery of external IP addresses.

If the value of this property is set to false, all processes with listeningports are considered for discovery.

You must set this property to true if you want to discover an OracleApplication Server or the WebLogic sensors. For example, if theWeblogicServerVersionSensor sensor tries to start using a local hostaddress, this property must be set to true.

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


ProblemThe lsof program is not properly set up to return information about allprocesses.

SolutionEnsure that you discover a supported version of Oracle Application Server.

The Oracle Application Sensor runs the opmnctl status command. Verifythat the system user that is used for discovery has privileges to run thiscommand.

The following list describes other possible reasons why the sensor does notstart:v The LiSt Open Files (lsof) program is not correctly set up to return

information about all processes. One of the following requirements forrunning the lsof program must be met:– The setuid (set user ID) access right flag must be set for the lsof

program file.– The user must use the sudo command to run the lsof program.

v The value of the com.collation.platform.os.ignoreLoopbackProcessesproperty in the $COLLATION_HOME/etc/collation.properties file is set to


false. The value must be set to true for the sensor to start. A value oftrue specifies that the processes that are listening on loopback interfacesare to be ignored.

v The Oracle Application Server libraries are not available on the TADDMserver. Oracle Application Server libraries must be made available on theTADDM server. Use the following property to specify the location ofthese libraries:com.collation.oracleapp.root.dir=lib/oracleapp

The default value for this property is lib/oracleapp. If the value for thisproperty is a relative directory, the directory is relative to$COLLATION_HOME, as shown in the following example:$COLLATION_HOME/lib/oracleapp.Whether the path is relative or absolute, the path must contain thefollowing two subdirectories:– j2ee– opmnThe Oracle Application Server libraries can be copied, or mounted usingthe Network File System (NFS), from an existing Oracle ApplicationServer installation. The following list identifies the required jar files:– j2ee/home/lib/ejb.jar– j2ee/home/lib/adminclient.jar– j2ee/home/lib/javax77.jar– j2ee/home/lib/jmxcluster.jar– j2ee/home/lib/jmx_remote_api.jar– j2ee/home/lib/jmxri.jar– j2ee/home/oc4jclient.jar– opmn/lib/argus.jar– opmn/lib/ons.jar– opmn/lib/opmnconfig.jar– opmn/lib/optic.jar– opmn/lib/repositorycheck.jar

The Oracle Application Server sensor fails

ProblemOracle Application Server discovery is not supported on all platforms.

SolutionEnsure that TADDM supports discovery of the Oracle Application Serveron your operating system.

Sensor fails in remote server

ProblemThe sensor fails in the remote server with an Agent terminated afterexceeding time limitnull error.

TADDM cannot find the Oracle Application Server libraries.

SolutionCheck the setting of the com.collation.oracleapp.root.dir property.


Sensor fails when trying to run discoverOpmnctl() method

ProblemThe sensor fails when it tries to run the discoverOpmnctl() method. Thepath of the TADDM service account on the Oracle Application Serversystem does not include the bin directory of the Oracle Application Serveror the user has no read/execute privileges to run the opmnctl statuscommand.

SolutionAdd the bin directory of the Oracle Application Server to the path of theTADDM service account on the Oracle Application Server system.

Sensor fails in remote server with Name not found errormessage in log file

ProblemThe sensor fails and the following error is displayed in the log file:javax.naming.NameNotFoundException: oc4j:internal/ResourceFinder not found

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

SAP CCMS server sensorThe SAP CCMS server sensor discovers SAP systems, SAP servers (ABAP andJava), and SAP components.


CCMSServerSensor

Prerequisites

The SAP CCMS server sensor requires JCo libraries to function. For informationabout JCo libraries, see the topic “Installing the SAP Java Connector (JCo)libraries”.

Depending on the specific application of SAP NetWeaver systems, you can use theSAP CCMS server sensor, the SAP SLD server sensor, or both to discover thissystem. SAP applications are installed on two different database schemasdepending on the application, and each are accessed by their respective runtimeenvironments. There is a runtime environment for Java instances (Java stack) andone for the Advanced Business Application Programming (ABAP) instances (ABAPstack):v Use the SAP CCMS server sensor to discover information where the SAP

NetWeaver system has applications based only on the ABAP stack.v Use the SAP SLD server sensor to discover information where the SAP

NetWeaver system has applications based only on the Java stack.v Use the SAP CCMS server sensor, the SAP SLD server, or both sensors to

discover information where the SAP NetWeaver system has applications basedon both the ABAP and Java stacks.



Installing the SAP Java Connector (JCo) librariesYou must install the SAP Java Connector (JCo) libraries for the specific operatingsystem.

To install the JCo library files, complete the following steps, where operating_systemrepresents 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


Run the ldd command against the libraries to see the dependencies, and ensurethat the dependencies are supported. The base operating system supports most ofthe dependencies.

On the Linux operating system, the libstdc++-libc6.2-2.so.3 library might not beinstalled by default. In that case, you must install the Red Hat packagecompat-libstdc++-296 to get the libstdc++-libc6.2-2.so.3 library files.

If the library dependencies are not supported, the following message is shown:Sensor failed in remote server: JCO.classInitialize (): Could not load middleware layer’com.sap.mw.jco.rfc.MiddlewareRFC’ JCO.nativeInit (): Could not initialize dynamic link library sapjcorfc[Can’t find library sapjcorfc (libsapjcorfc.so) in sun.boot.library.path or java.library.path sun.boot.library.path={full-path-list}


To configure the access list, complete the following steps:1. Select 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 authorizationsmentioned in the following list)

b. Passwordc. Client ID

The following lists the authorizations that are required by the SAP user being usedfor CCMS sensor discovery. Grant all (*) privileges to the following authorizationobjects:

S_RFCAuthorization Check for RFC Access

S_ADMI_FCDSystem Authorizations

S_BTCH_ADMBackground Processing: Background Administrator


S_DATASETAuthorization for file access

S_LOG_COMAuthorization to Execute Logical Operating System Commands

S_RZL_ADMCC Control Station: System Administration

S_XMI_LOGInternal Access Authorization for XMI Log

S_XMI_PRODAuthorization for External Management Interfaces (XMI)






Troubleshooting the sensorThis topic describes common problems that occur with the SAP CCMS serversensor and presents solutions for those problems.


ProblemThe following errors occur, which means that the class path does notcontain the path for the sapjco.jar file:Sensor failed in remote server: com/sap/mw/jco/JCOMSG_ERROR: java.lang.NoClassDefFoundError: com/sap/mw/jco/JCO

SolutionThe sapjco.jar file should be in the $COLLATION_HOME/ lib/JCo/libdirectory, this file path should be in the class path.

Look for the following message in the DiscoverManager.log file:adding this jar file to the list: {jar-file-path}

The jar-file-path should be $COLLATION_HOME/ lib/JCo/lib/sapjco.jar.

Sensor cannot find library file

ProblemThe following errors occur, which means that the sensor cannot find thelibsapjcorfc.so library file in sun.boot.library.path or injava.library.path:


Sensor failed in remote server:JCO.classInitialize (): Could not load middleware layer’com.sap.mw.jco.rfc.MiddlewareRFC’JCO.nativeInit (): Could not initialize dynamic link library sapjcorfc[Can’t find library sapjcorfc (libsapjcorfc.so) in sun.boot.library.pathor java.library.path sun.boot.library.path={full-path-list}

SolutionEnsure that the libsapjcorfc.so library file is in the $COLLATION_HOME/lib/JCo/operating system (Linux, AIX, or Solaris) path. Also ensurethat this path is present in the full-path-list for sun.boot.library.path thatis mentioned in the preceding message. If the path is present, the problemmight be due to library dependencies that have not been met. Run the lddcommand against the libsapjcorfc.so library file to get a list of the librarydependencies, and verify that your environment supports thesedependencies.

No CCMS access list is provided for an IP address

ProblemThe following error occurs:ERROR collation. AnchorClient - No CCMS access list provided for:{ip-address}

This error can occur for one of the following reasons:v No access list is provided for the sensor.v The sensor cannot successfully connect to the IP address using the access

list information that is provided by the user.

SolutionIf you provided the necessary access list credentials, verify the followingitems:v Ensure that the user ID meets the specified minimum 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: {clientid}

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

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


SLDServerSensor

Prerequisites

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


Depending on the specific application of SAP NetWeaver systems, you can use theSAP CCMS server sensor, the SAP SLD server sensor, or both to discover thissystem. SAP applications are installed on two different database schemasdepending on the application, and each are accessed by their respective runtimeenvironments. There is a runtime environment for Java instances (Java stack) andone for the Advanced Business Application Programming (ABAP) instances (ABAPstack):v Use the SAP CCMS server sensor to discover information where the SAP

NetWeaver system has applications based only on the ABAP stack.v Use the SAP SLD server sensor to discover information where the SAP

NetWeaver system has applications based only on the Java stack.v Use the SAP CCMS server sensor, the SAP SLD server, or both sensors to

discover information where the SAP NetWeaver system has applications basedon both the ABAP and Java stacks.



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 onyour configuration, you might also need to assign the SAP_J2EE_ADMIN role tothe SAP account.


com.collation.discover.agent.SLDServerAgent.connectionTimeout=30The default value is 30, which means 30 seconds. The value must be aninteger.

This property specifies the maximum amount of time (in seconds) to waitfor the initial SLD connection test.

Connection timeouts are recorded in the DiscoveryManager.log file. If thesetimeouts occur, increase the value of this property.

The property can be scoped to a specific host name or IP address, asshown in the following examples:com.collation.discover.agent.SLDServerAgent.connectionTimeout.Linux.1.2.3.4=60

com.collation.discover.agent.SLDServerAgent.connectionTimeout.SunOS=45






com.collation.discover.agent.SLD.PoolSizeThis property specifies the maximum number of connection pools to bemaintained alive to an SLD server. These connections can be reused foradditional requests. The default value is 16.

com.collation.sudoCommandThis property specifies the sudo command name. The default value is sudo.

Troubleshooting the sensorThis topic describes common problems that occur with the SAP SLD server sensorand presents solutions for those problems.

SLDServerAgent connection timeout errors

ProblemSLDServerAgent connection timeout errors are found in theDiscoverManager.log file.

SolutionIn the $COLLATION_HOME/etc/collation.properties file, increase the valueof the com.collation.discover.agent.SLDServerAgent.connectionTimeoutproperty until the connection is successful.

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


SMBServerSensor


The sensor creates the following model objects:v sys.ServiceAccessPointv sys.SMBExportv sys.SMBSAPv sys.SMBService

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

Error message uncaught exception results when running adiscovery

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


SolutionThis message indicates that there is a problem with Windows ManagementInstrumentation (WMI) service. See the Windows computer system sensor“Troubleshooting the sensor” topic for information about WMI problemsand solutions.

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


SMSServerSensor

Limitations

The sensor does not discover information about SMS Server client computersystems as CDM ComputerSystem instances but instead as CDMSMSCollectionClients instances.

Therefore, the discovery of an SMS Server cannot be used in place of directdiscovery of the hosts that are part of the SMS Server infrastructure.


The sensor creates the following model objects:v app.sms.SMSAdvertizementsv app.sms.SMSCollectionsv app.sms.SMSCollectionClientsv app.sms.SMSHierarchyv app.sms.SMSPackagev app.sms.SMSProgramv app.sms.SMSQueryv app.sms.SMSReportsv app.sms.SMSResourcev app.sms.SMSServerProcessv app.sms.SMSSiteBoundariesv app.sms.SMSSiteComponentsv app.sms.SMSSiteServer



com.collation.discover.agent.SMSServerAgent.GetReportsIf set to true, SMS Report information is captured by the sensor and storedas instances of the CDM SMSReports class. The default value is false.

com.collation.discover.agent.SMSServerAgent.GetQueriesIf set to true, SMS predefined queries are captured by the sensor andstored as instances of the CDM SMSQuery class. The default value is false.


com.collation.discover.agent.SMSServerAgent.GetClientsIf set to true, information about SMS collection clients is captured by thesensor and stored as instances of the CSM SMSCollectionClients class. Thedefault value is false.

com.collation.discover.agent.SMSServerAgent.MaxNrClientsThe maximum number of clients about which information is captured bythe sensor. The default value is 100.

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


SysImagerServerSensor and SysImagerNodeSensor

Prerequisites

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


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



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

SysImagerServerAgentConfiguration.2. Set the following required attributes:

masterServerNamesThe IP addresses or host names of SysImager master nodes. Thisproperty must be set to start the SysImager server sensor.

3. If appropriate, set some of the following attributes, or accept the default values.

configFileLocationThe location of the SysImager configuration file. The default value is/etc/systemimager/systemimager.conf.


clusterXMLFileLocationThe location of the SysImager cluster configuration file. The defaultvalue is /etc/systemimager/cluster.xml.

clusterConfigCommandThe command to display configuration information about theSysImager cluster. The default value is si_clusterconfig -g.

lsImageCommandThe command to display images of the SysImager cluster. The defaultvalue is si_lsimage -v.

imagesDiscoveryModeThis property is not used.

overridesDiscoveryModeThe depth of file capture for overrides. The valid values are as follows:v 0: No file information is captured.v 1: Only the file name and file information are captured.v 2: All file information and content are captured.


overridesDiscoveryPatternThe filename pattern for files under the overrides directory. The defaultvalue is "*".

preInstallScriptsContentThe depth of file capture of the scripts executed before install. Thevalid values are as follows:v 0: No file information is captured.v 1: Only the file name and file information are captured.v 2: All file information and content are captured.


postInstallScriptsContentThe depth of file capture of the scripts executed after install. The validvalues are as follows:v 0: No file information is captured.v 1: Only the file name and file information are captured.v 2: All file information and content are captured.


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

doPingNodesSpecifies whether ping sensors are run against discovered SysImagernodes.


SysImagerServerSensor uses SysImager Server access entry. If this is not available,the sensor uses ComputerSystem access entry to access the SysImager server.


SysImagerNodeSensor uses ComputerSystem access entry to access SysImagernodes.

Veritas cluster sensorThe Veritas cluster sensor discovers Veritas Cluster Servers.

The sensor collects general information about the Veritas Cluster Server and theservices that are installed on it. Services are organized in service groups andcontain information about the resources that are used.

The sensor can create relationships between the services and applications installedon a cluster.


VeritasClusterSensor

Security issues

The user account for discovering Computer Systems is also used for runningVeritas commands. By default, execute permission on the Veritas Cluster directoryand commands is required. The sensor uses the following commands:v hastatus

v haclus

v hasys

v hares

v hagrp

v hatype

v hauser

Before running Veritas commands, a login to the cluster is performed on systemsthat support the Veritas halogin command. These are UNIX systems with VCSversion 4.1 and higher. The sensor logs in using the user name and password fromthe High Availability Solutions access list entry.

To specify that the sensor should use sudo when running Veritas Cluster Servercommands on Linux or UNIX systems, configure the appropriate parameters in thecollation.properties file.

To run the commands without using the sudo command, the TADDM serviceaccount must be a member of the Veritas Admin Group on the target.

You must configure sudo ndd with NOPASSWORD for the access user.


The sensor creates the following model objects:v app.ConfigFilev app.SoftwareInstallationv app.veritas.cluster.VCSClusterv app.veritas.cluster.VCSHADServerv app.veritas.cluster.VCSLocalServiceGroup


v app.veritas.cluster.VCSResourceConfigurationv app.veritas.cluster.VCSServiceGroupv app.veritas.cluster.VCSSystem



The following VeritasClusterSensor attribute can be modified:

discoveryModeThe default value for the discoveryMode attribute is 1 (the sensor runs inlightweight mode).

To generate more configuration items and store them in the database,specify 0.

Alternatively, open the $COLLATION_HOME/etc/discover-sensors/VeritasClusterSensor.xml and modify the attribute.


To configure the access list, complete the following steps:1. Select High Availability Solutions as the Component Type.2. Enter the following required information, User name and Password.


The following properties specify that the sensor uses sudo to elevate privilegeswhen running Veritas Cluster Server commands:v com.collation.discover.agent.command.hastatus.Linux=sudo

/opt/VRTSvcs/bin/hastatus

v com.collation.discover.agent.command.haclus.Linux=sudo /opt/VRTSvcs/bin/haclus

v com.collation.discover.agent.command.hasys.Linux=sudo /opt/VRTSvcs/bin/hasys

v com.collation.discover.agent.command.hares.Linux=sudo /opt/VRTSvcs/bin/hares

v com.collation.discover.agent.command.hagrp.Linux=sudo /opt/VRTSvcs/bin/hagrp

v com.collation.discover.agent.command.hatype.Linux=sudo /opt/VRTSvcs/bin/hatype

v com.collation.discover.agent.command.hauser.Linux=sudo /opt/VRTSvcs/bin/hauser

You can scope each property to a specific operating system or IP address, as in thefollowing examples:v com.collation.discover.agent.command.hastatus =sudo /opt/VRTSvcs/bin/

hastatus


v com.collation.discover.agent.command.hastatus.Linux=sudo/opt/VRTSvcs/bin/hastatus

v com.collation.discover.agent.command.hastatus.Linux.192.168.1.1=sudo/opt/VRTSvcs/bin/hastatus

Specify the sudo option for an operating system only if it required for all systemsrunning that operating system; otherwise, specify the option only for the specificIP addresses where the sudo command is configured. You must configure sudo nddwith NOPASSWORD for the access user.

On each target system for which privilege escalation is needed, configure the sudocommand with the NOPASSWD option. Otherwise, your discovery hangs until theTADDM server times out.

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

The sensor fails

ProblemThe VeritasClusterSensor sensor fails.

SolutionIf the sensor fails and the logs point to some of the commands timing out,this error could indicate a failed login to the cluster. Verify that the correctuser name and password for the Veritas Cluster is used.

VMware Virtual Center server sensorThe VMware Virtual Center server sensor discovers VMware Virtual Center serversand the elements that are managed by the servers. VMware Virtual Center is nowknown as VMware vCenter Server.


VirtualCenterSensor

Elements discovered by the sensor

The sensor discovers the following elements that are managed by the VirtualCenter server:v Data centers in a virtual centerv VMware clusters created in each data centerv Memory resource poolsv CPU resource poolsv VMware ESX servers managed by a virtual centerv Virtual computers on each managed VMware ESX serverv Virtual switches and port groups in each virtual switchv Distributed virtual switches, uplinks, and port groups in each distributed virtual

switch.v Data stores created in each data center


VMware ESX servers, which are discovered by the VMware ESX and VirtualCenter server sensors, are merged after the discovery.

In the Discovery Management Console, a VM (virtual machine) is represented by acomputer system icon that is blue and transparent.

The Virtual Center server sensor uses the VMware API to discover data, and theVMware API collects the following data:v Attribute data that is required to match naming rules and to create a valid

stand-alone VM instancev Certain basic information that the VMware ESX server provides through the

vmware-cmd commandv The attribute primaryMACAddress, which is required to reconcile the shallow

virtual instance with any physical instance that can be discoveredv The attribute vmwareUUID, which is required to reconcile the virtual computer

instances that are discovered before and after migrations using VMotion.

There are four user scenarios for a Virtual Center and ESX server discovery:v All-inclusive: The discovery scope contains ESX and Virtual Center servers.

The result displays the ESX and Virtual Center servers. ESX servers that aremanaged by the Virtual Center servers are displayed in one of the data centersor clusters in the virtual center. All virtual and physical instances, discovered bythe Virtual Center and ESX sensors are reconciled. The physical instances have avirtual attribute set to true.

v ESX server Only: The discovery scope contains ESX servers.The result displays the ESX servers that are discovered by the ESX sensor. ESXservers with typical attributes for example, model are displayed. The VirtualCenter sensor is not started.

v Virtual Center Server Only: The discovery scope contains Virtual Center servers.The result displays the ESX servers and virtual computers that are discovered bythe Virtual Center sensor.

v Virtual Center and VM: The discovery scope contains Virtual Center servers andall virtual computers.The results display all the virtual computers, with all the physical, and virtualattributes set to true. The virtual computers are displayed in the Virtual Systemstab of the respective ESX server.

Prerequisites

The VMware Virtual Center server service is running on the target windowscomputer.

Security issues

To discover the VMware Virtual Center server, you must set read-only permissionsfor the TADDM service account. The service account must have administratorprivileges.

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



net.IpInterface (for ESX server only)

v Namev IpAddress

net.L2Interface

v Name (for ESX server only)v Index (for Virtual Machines)v HwAddress

process.CPUResourcePool

v Namev Labelv Limitv Reservationv SharesLevelv SharesValue

process.MemoryResourcePool

v Namev Labelv Limitv Reservationv SharesLevelv SharesValue

relation.AllocatedTo

v Source (MemoryResourcePool or CPUResourcePool)v Target (Memory or CPU)

relation.DonatedTo

v Source (for ESX server only)v Target (MemoryResourcePool or CPUResourcePool)

sys.CPU

v NumCPUsv Parent

sys.DNSResolveEntry (for ESX server only)

v ServerIPv Parent

sys.Memory

v MemorySizev Parent

sys.NFSFileSystem

v serverNamev MountPointv Typev Capacity


v AvailableSpacev MaxFileSizev StorageExtentv FileSystemBlockSizev MaxBlocks

sys.unix.UnixFileSystem (for Virtual Machine File System)

v MountPointv Typev Capacityv AvailableSpacev MaxFileSizev StorageExtentv FileSystemBlockSizev MaxBlocks

sys.vmware.DataCenter

v Namev Labelv Parentv Systemsv Clustersv VirtualSwitches

sys.vmware.VirtualCenter

v Namev Hostv UIDv VersionStringv ApiVersionv Vendorv BuildLevelv VirtualCenterPortv MaxDBConnectionsv ClientTimeoutNormalv ClientTimeoutLongv WebServiceHttpPortv WebServiceHttpsPort

sys.vmware.VMWareCluster

v Namev Labelv DPMEnabledv DRSEnabledv HAEnabledv Parentv RootMemoryResourcePoolv RootCPUResourcePool


sys.vmware.VMWareDataStore

v Namev Labelv Typev DataStoreURLv Capacityv FreeSpacev IsAccessiblev AccessModev IsMultipleHostsAccessv BasedOnv DataCenter

sys.vmware.VmwareESX

v OSNamev OSVersion

sys.vmware.VMWarePortGroup

v ActiveUplinksv L2Interfacesv Namev Parentv StandbyUplinksv Uplinks

sys.vmware.VmwareUnitaryComputerSystem

v Namev Fqdnv ObjectTypev Manufacturerv Modelv CPUSpeedv CPUTypev LifecycleStatev NumCPUsv MemorySizev AvailableMemoryForAllVMsv CurrentMemoryForAllVMsv SwapMemorySizev ServiceConsoleMemorySizev VmotionEnabled

sys.vmware.VMWareVirtualSwitch

v DataCenterv Namev MTUv NumPortsv NumPortsAvailable


v ObjectTypev PortGroupsv Parentv UplinkPortGroupsv Interfaces

sys.vmware.VMWareDVUplink

v L2Interfacesv Name

Multiple virtual machines, such as the following operating systems and virtualsystems:

sys.darwin.Darwinsys.darwin.DarwinUnitaryComputerSystemsys.dos.Dossys.dos.DosUnitaryComputerSystemsys.freebsd.FreeBSDsys.freebsd.FreeBSDUnitaryComputerSystemsys.linux.Linuxsys.linux.LinuxUnitaryComputerSystemsys.netware.Netwaresys.netware.NetwareUnitaryComputerSystemsys.sun.Solarissys.sun.SunSPARCUnitaryComputerSystemsys.windows.WindowsComputerSystemsys.windows.WindowsOperatingSystem

The following attributes are associated with these model objects:v uuidv VMIDv OSNamev Fqdn (if VMware Tools are running on virtual machine)v MemorySizev NumCPUsv FaultTolerance

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

Configuring the non-root user to run the sensorYou must add the users credentials to the Read-Only role by using the VMwareInfrastructure Client for non-root users.

By default, non-root users do not have permission to run the Virtual Center serversensor. To enable this function, for non-root users add the users credentials to theRead-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:


1. From the VMware Infrastructure Client, log on to the VMware Virtual Centerserver 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.


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 theVMware Virtual Center server.

v To access the VMware Virtual Center server using an account with read-onlyprivileges:1. Use Virtual Center Server as the Component Type.2. Specify the access information (user name and password).

Use this method to discover VMware Virtual Center servers in an IBM TivoliMonitoring environment. This method grants access to the Virtual Centerserver only and does not grant access to the host computer system. In thediscovery profile include the VMware Virtual Center server sensor and theIBM Tivoli Monitoring Scope sensor.

Troubleshooting the sensorThis topic describes common problems that occur with the VMware Virtual Centerserver sensor and presents solutions for those problems.

Serial number and System ID are blank in the Details panel ofthe VMware ESX server

ProblemThe attributes Serial number and System ID are blank in the Details panelof the VMware ESX server. The attributes for the file system are notdiscovered.

SolutionThe attributes are not displayed because the information is not availablefrom the API. For the L2Interface layer, only the name and hardwareaddresses are collected.

Verify that the ESX server and Virtual Center server are included in thediscovery scope. Check the credentials, to ensure that the correctpermissions are used for accessing the ESX server and Virtual Centerserver, and run the discovery again.


The sensor fails with a timeout error

ProblemIf the Virtual Center server is managing many ESX hosts and virtualcomputers then the sensor can fail with a timeout error message, An erroroccurred. Sensor timed out.

SolutionIn the etc/collation.properties file, increase the value for the sensor torun, where value is the number of milliseconds allowed for the sensor torun:com.collation.discover.agent.VirtualCenterSensor.timeout=value

The default value is 3600000 .

Elements managed by the VMware Virtual Center server are notdiscovered

ProblemElements are not discovered on VMware vCenter Server Version 4.1running on Microsoft Windows Server 2003. The following error messagesexist:v The VirtualCenterServer log contains:

AxisFaultfaultCode: {http://xml.apache.org/axis/}HTTPfaultSubcode:faultString: (503)Service UnavailablefaultActor:faultNode:faultDetail:{}:return code: 503503 Service Unavailable {http://xml.apache.org/axis/}HttpErrorCode:503

(503)Service Unavailable )

v The VMware Virtual Center server vpxd log contains:Connection to localhost:8085 failed with error class Vmacore::SystemException(Normally allowed each socket address (protocol / network address / port)is used only once.

v Running a netstat -ban | findstr 8085 command from the VMwareVirtual Center server shows many TCP/IP Ports are left open in aLAST_ACK state.

SolutionThe behavior occurs because ephemeral ports, temporary ports that areused for client server communications, are not closed upon use. Ephemeralports are limited to a range of ports and are only valid for the duration ofthe connection. In this case, on certain Microsoft Windows operatingsystems, certain connections leave the ports in a LAST_ACK state on theVirtual Center server. The range of ports can be exhausted after a time andwhen this situation happens, connectivity can fail until a port is freed.

To prevent this event occurring, go to the Microsoft website athttp://support.microsoft.com and search for KB979230. You can thendownload and install the fix.

WebLogic sensorThe WebLogic sensor discovers Oracle WebLogic Server application servers andWebLogic Server version information.


http://support.microsoft.com

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

Sensor name that is used in the GUI and logsv WeblogicSensorv WeblogicSensor2v WeblogicServerVersionSensor

Prerequisites

The WeblogicSensor sensor requires additional JAR files that are part of the OracleWebLogic Server installation. You must copy these JAR files to the followingdirectories on the TADDM server:v For Linux, 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 createin the $COLLATION_HOME/lib/weblogic/ directory. However, each directory must beconfigured in the WeblogicVersionSensor.xml file.

Security issues

The TADDM server requires the WebLogic system login name and the passwordthat is used to log in to the WebLogic Product Console.

Limitations

TADDM does not support WebLogic discovery with the WebLogic sensor whenusing SSL.

The WebLogic sensor must not be run with the WebLogic SSH pluggable sensors inthe same discovery. Do not enable the WebLogic sensor and the WebLogic SSHpluggable sensors in the same discovery profile.


The sensor creates the following model objects:v app.AppConfigv app.AppServerv app.ConfigFilev app.j2ee.weblogic.WebLogicServerv app.j2ee.J2EEComponentv app.j2ee.J2EEDeployedObjectv app.j2ee.J2EEDomain


v app.j2ee.J2EEModulev app.j2ee.J2EEResourcev app.j2ee.weblogic.WebLogicClusterv app.j2ee.weblogic.WebLogicConnectorv app.j2ee.weblogic.WebLogicConnectorModulev app.j2ee.weblogic.WebLogicDomainv app.j2ee.weblogic.WebLogicEJBModulev app.j2ee.weblogic.WebLogicJ2EEApplicationv app.j2ee.weblogic.WebLogicJDBCConnectionPoolv app.j2ee.weblogic.WebLogicJDBCDataSourcev app.j2ee.weblogic.WebLogicJDBCDriverv app.j2ee.weblogic.WebLogicJDBCMultiPoolv app.j2ee.weblogic.WebLogicJDBCTxDataSourcev app.j2ee.weblogic.WebLogicJMSServerv app.j2ee.weblogic.WebLogicJMSStorev app.j2ee.weblogic.WebLogicJTAv app.j2ee.weblogic.WebLogicMachinev app.j2ee.weblogic.WebLogicSSLSettingsv app.j2ee.weblogic.WebLogicServerv app.j2ee.weblogic.WebLogicServletv app.j2ee.weblogic.WebLogicVirtualHostv app.j2ee.weblogic.WebLogicWebContainerv app.j2ee.weblogic.WebLogicWebModulev app.ProcessPoolv app.SoftwareContainerv app.web.WebVirtualHost

Configuring the sensorBefore using the WebLogic sensor, you must configure it.

Copying JAR files to the TADDM serverYou must copy additional JAR files that are part of the Oracle WebLogic Serverinstallation to the TADDM server.

Before starting a discovery, copy the required JAR files for your WebLogic versionto the $COLLATION_HOME/lib/weblogic/$VERSION_DIR/ directory:

Table 7. Required WebLogic JAR files

WebLogic version Required JAR files

WebLogic version 9 (allreleases)

v $WEBLOGIC_HOME/server/lib/weblogic.jarv $WEBLOGIC_HOME/server/lib/webservices.jarv $WEBLOGIC_HOME/server/lib/wljmxclient.jarWebLogic version 10.0

through 10.2

WebLogic version 10.3 v $WEBLOGIC_HOME/server/lib/wlfullclient.jar

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


Creating a wlfullclient.jar for the WebLogic sensorYou must create a wlfullclient.jar file for a client application. This JAR file isrequired for WebLogic version 10.3, or later.

To create a wlfullclient.jar file for the WebLogic sensor, complete the followingsteps:1. Change to the directory where the WebLogic Server is installed:

cd WL_HOME/server/lib

2. Create the wlfullclient.jar file:java -jar ../../../modules/com.bea.core.jarbuilder_X.X.X.X.jar

where X.X.X.X is the version number of the JarBuilder module in theWL_HOME/server/lib directory. For example:java -jar ../../../modules/com.bea.core.jarbuilder_1.0.1.0.jar

3. Copy and bundle the wlfullclient.jar file with the client application.4. Add the wlfullclient.jar file to your Java class path.

Editing the WeblogicVersionSensor.xml fileYou must edit the WeblogicVersionSensor.xml file.

The configuration file is located in the following directories:v On Linux, Solaris, AIX, and Linux on System z operating systems, the file is in

the $COLLATION_HOME/etc/discover-sensors/ directory.v On Windows operating systems, the file is in the %COLLATION_HOME%\etc\

discover-sensors\ directory.

The code sample in this section shows how to configure the directories and JDKusing XML tags. In this example, the following directories and JDK pairs areconfigured: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 JARfiles. 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 onlyversion of JDK that is valid is 1.5.0. If the WeblogicServerVersionSensor sensordoes 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>


</item></weblogicClassPath></configuration>

</SensorPlugin>

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

Editing the WeblogicSensor2.xml fileYou must edit the WeblogicSensor2.xml file.

The configuration file is located in the following directories:v On Linux, Solaris, AIX, and Linux on System z operating systems, the file is in

the $COLLATION_HOME/etc/discover-sensors/ directory.v On Windows operating systems, the file is in the %COLLATION_HOME%\etc\

discover-sensors\ directory.

Use the following tags to edit the WeblogicSensor2.xml file:<SensorPlugin xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="http://www.ibm.com/xml/schemas/taddm/FixedSensorSchema.xsd">

<name>WeblogicSensor2</name><osgiId>com.ibm.cdb.discover.sensor.app.j2ee.weblogic2_7.1.0</osgiId>

<sensorClassName>com.collation.discover.agent.app.j2ee.WeblogicAgent2</sensorClassName><seedClassName>com.collation.discover.seed.app.j2ee.WeblogicSeed2</seedClassName><resultClassName>com.collation.discover.result.app.j2ee.WeblogicServerResult2</resultClassName><convertorClassName>com.collation.discover.engine.seedfactory.SoftwareConvertor</convertorClassName>

<defaultProfiles><profile>Level 3 Discovery</profile>

</defaultProfiles>

<configuration className="com.ibm.cdb.discover.sensor.configuration.WeblogicServerAgent2Configuration"><allowSensorToBePooledInJVM>true</allowSensorToBePooledInJVM><domains>

<item><domainAddress>

<address>DOMAIN_IP</address><port>DOMAIN_PORT</port>

</domainAddress><addresses>

<item><address>IP_OF_FIRST_INTERFACE_ADMIN_SERVER_IS_USING</address><port>PORT_ ADMIN_SERVER_IS_USING </port>

</item><item>

<address>IP_OF_SECOND_INTERFACE_ADMIN_SERVER_IS_USING</address><port>PORT_ ADMIN_SERVER_IS_USING </port>

</item></addresses>

</item></domains>

</configuration></SensorPlugin>

You can use this configuration when the WebLogic server is using multipleinterfaces on the Domain Admin Server.

In this case, the value of DOMAIN_IP and DOMAIN_PORT is used instead ofIP_OF_FIRST_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING andIP_OF_SECOND_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING.

Copying JAR files to discover older versions of WebLogicapplication serversTo discover servers running older versions of WebLogic, copy the JAR files to theTADDM server.

In most cases, if you have the JAR files from the current version of WebLogic, youcan also discover servers running older versions of WebLogic. When this methoddoes not work, complete the following steps:1. Run a discovery with the current set of JAR files.2. Stop the TADDM server.3. Copy the JAR files for the older or different version of the WebLogic server to

the corresponding directories.4. Start the TADDM server.5. Run the discovery for the WebLogic server.


To configure the access list, complete the following steps:1. Select Application Servers as the Component Type.2. Select Weblogic as the Vendor.3. Specify the following required information:


Ensure the WebLogic user you add to the access list has the following information:v Administrator privilegesv Password

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

com.collation.agent.weblogic.domainsconfigurationUsed when the WebLogic server uses multiple interfaces on the DomainAdmin Server (domain_ipX:domain_portX is used instead oflisten_ipN:listen_portN).

The syntax of the property is as follows:com.collation.agent.weblogic.domainsconfigurationdomain_ipA:domain_portA listen_ip1:listen_port1,listen_ip2:listen_port2;domain_ipB:domain_portB ...

For example:com.collation.agent.weblogic.domainsconfiguration=

9.158.143.20:7001-9.158.143.20:7002,9.158.143.50:7001;9.158.143.20:7001-9.158.143.20:7002,9.158.143.50:7003

com.collation.agent.weblogic.protocolsBy default, this property is disabled, and the T3 protocol is used. If youuncomment this property, you can specify the list of protocols (separatedby commas) to be used by the WebLogic sensors, as shown in thefollowing example:com.collation.agent.weblogic.protocols=t3,http

In this example, the T3 protocol is the first protocol that is tried. If thisprotocol fails, the HTTP protocol is used. If you want to use the HTTPprotocol to connect to a WebLogic server instance, you must enable HTTPtunneling for that instance using the WebLogic Console.


The only valid values are t3 and http. If you code an incorrect value, suchas a value with typographical errors, the WebLogic server cannot processthe request properly and might stop.





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

WebLogic sensor does not start

ProblemThe WebLogic sensor does not start.

SolutionPerform the following actions:v For each version of the WebLogic server, copy the JAR files from the

WebLogic installation to the $COLLATION_HOME/lib/weblogic/VERSIONdirectory. Verify the sensor configuration in the $COLLATION_HOME/etc/discover-sensors/WeblogicVersionSensor.xml file.

v Verify that the WebLogic Server port and IP address are reachable andthat the WebLogic server uses the Java Management Extensions (JMX)communication protocol that is supported by TADDM. Configure thecom.collation.agent.weblogic.protocols property in thecollation.properties file.

v If the WebLogic Sensor starts when using the local host address(127.0.0.1) and fails or discovers nothing, set the value of the followingproperty in the collation.properties file to true:com.collation.platform.os.ignoreLoopbackProcesses=true

WebLogic sensor fails

ProblemThe WeblogicServerVersion sensor fails.

SolutionCopy the required WebLogic JAR files to the TADDM installation (seeConfiguring the sensor for details). Alternatively, the authenticationinformation is missing or incorrect.



ProblemThe following error is in the local-anchor*.log, which typically meansthat the WebLogic security authentication information is missing orincorrect:Sensor failed in remote server:An error occurred in the null sensor.

SolutionEnsure that you have the correct security authentication information. TheTADDM server requires the WebLogic system login name and thepassword that is used to log in to the WebLogic Product Console.

Message states that nothing exists to be discovered

ProblemThe WebLogic sensor runs and completes successfully with the followingmessage:There was nothing to be discovered.

SolutionThis message occurs when you are discovering a WebLogic ApplicationServer. Although this situation is not a problem, ensure that the WebLogicsensor runs against the WebLogic Admin Server.

Sensor fails with WebLogic 10.x

ProblemThe WeblogicServerVersion sensor fails only with WebLogic 10.x.

SolutionWeblogicVersionSensor uses an external command to identify the versionof WebLogic. On some WebLogic 10.x installations, this command returnsan unexpected empty string which causes the WeblogicVersionSensor tofail.

As a workaround, use the JAR files from a WebLogic 9.x installation.WebLogic 9.x JAR files work with WebLogic 10.x.

WebLogic sensor fails to discover WebLogic AdministrationServer

ProblemWhile attempting discovery of a WebLogic Administration Server, theWebLogic sensor fails as a result of a non-functioning DNS.

SolutionDiscoveries involving the sensors related to WebLogic AdministrationServers must have working DNS. As a workaround, changecom.collation.platform.os.disableRemoteHostDNSLookups to true, andensure that the TADDM server always has the correct DNS search path.

WebLogic sensor fails due to timeout

ProblemThe WebLogic sensor fails due to timeout.

SolutionIncrease value of the com.collation.discover.agent.NAME timeout propertyin the collation.properties file, where NAME represents the name of the


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

WebLogic sensor fails after migration

ProblemThe WebLogic sensor fails after migration.

SolutionEnsure that you run the $COLLATION_HOME/bin/template-upgrade.sh script.

Sensor fails due to T3 problem

ProblemThe WeblogicServerVersion sensor fails due to inaccessible T3 protocol.

SolutionIn some installations, the T3 protocol might be blocked. In this case,configure the WebLogic Servers to use the http protocol, and configure theWeblogicSensors to use http as well.

For example:com.collation.agent.weblogic.protocols=t3,http

WeblogicServerVersion fails due to timeout when issuing aversion command

ProblemThe weblogicServerVersion times out while issuing the version command.The problem can be due to the port being blocked by the firewall. Thefollowing example shows port number 6079 is blocked by a firewall:2009-09-09 12:29:38,802 DiscoverManagerDiscoverWorker-11 WeblogicServerVersionSensor-169.70.70.100-6079 DEBUGj2ee.WeblogicServerVersionAgent - Executing command: -cp/opt/IBM/taddm/dist/lib/weblogic/10.0/weblogic.jar:/opt/IBM/taddm/dist/lib/weblogic/10.0/webservices.jar:/opt/IBM/taddm/dist/lib/weblogic/10.0/wljmxclient.jar -Duser.language=en -Duser.region=US weblogic.Admin -urlt3://169.70.70.100:6079 -username confadmin -password XXX VERSION 2009-09-0912:29:39,133 DiscoverManager DiscoverWorker-11WeblogicServerVersionSensor-169.70.70.100-6079 DEBUG util.OsCommand - Commandexecuted, capturing output 2009-09-09 12:33:03,526 DiscoverManagerDISCOVER_SENSOR_CLEANUP_DiscoverWorker-11WeblogicServerVersionSensor-169.70.70.100-6079 DEBUGj2ee.WeblogicServerVersionAgent - JavaCommand errorjava.lang.InterruptedException at java.lang.Object.wait(Native Method) atjava.lang.Object.wait(Object.java:231) at java.lang.Thread.join(Thread.java:680)at com.collation.platform.util.OsCommand.execute(OsCommand.java:411)

SolutionThis sensor uses a protocol other than SSH for host access, the appropriateport needs to be open between the TADDM server and the target. In caseswhen a firewall prevents direct access from the discovery server to certainhosts or devices, you can specify a computer system that does have accessto the hosts or devices to be an anchor host.


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

Sensor name that is used in the GUI and logsv WeblogicLauncherSensorv WeblogicApplicationSensorv WeblogicDomainSensorv WeblogicServerSensor

Security issues

The WebLogic pluggable sensors require computer system credentials or WebLogiccredentials.

Limitations

For a discovery to run, the WebLogic pluggable sensors must have access to thedomain configuration files. The location of the domain configuration directory canbe determined by the sensor in the following specific situations:v The WebLogic server is started as a Windows service.v The WebLogic server is started as a Windows or UNIX process, and it is started

with the following argument:-Dpredefined.domain.config.dir=domain_directory

v The WebLogic server is started as a Windows or UNIX process, and it is startedwith the following argument:-Dweblogic.RootDirectory=domain_directory

v The WebLogic server is started as a UNIX process, and the location of thedomain configuration directory is set as one of the following processenvironment variables:– DOMAIN_HOME– LONG_DOMAIN_HOME– PWD– OLD_PWD– OLDPWD

v The WebLogic server is started as a Windows or UNIX process, and the processcontains a variable with the path to the domains subdirectory. All domains are inthe user_project_directory/domains/domain_name directory. A search for theconfiguration file is carried out in the directory and all sub directories defined inthe path for the domains.For example, if a WebLogic process contains the variable-Dweblogic.system.BootIdentityFile=/home/weblogic/bea/my_user_projects/domains/domain92/aaa/boot.properties, the following paths are searched for theconfig_file_name:– /home/weblogic/bea/my_user_projects/domains/domain92/

– /home/weblogic/bea/my_user_projects/domains/domain92/config/

v The WebLogic server is started as a Windows or UNIX process, and the processcontains a variable with the path to the servers subdirectory. The servers


directory is located in the Domain home directory. A search for the configurationfile is carried out in the directory and all sub directories defined in the path forthe servers.For example, if a WebLogic process contains the variable-Dweblogic.system.BootIdentityFile=/home/weblogic/bea/my_user_projects/domains/domain92/servers/MS92_1/data/nodemanager/boot.properties, the following paths aresearched for the config_file_name:– /home/weblogic/bea/my_user_projects/domains/domain92/

– /home/weblogic/bea/my_user_projects/domains/domain92/config/

v The WebLogic server is started as a Windows or UNIX process, and the processcontains a variable with the path to the user_project subdirectory. Theuser_projects directory is the default directory containing WebLogic projects. Asearch for the configuration file is carried out in the directory and all subdirectories defined in the path for the user_projects.For example, if a WebLogic process contains the variable-Dweblogic.system.BootIdentityFile=/home/weblogic/bea/my_user_projects/domains/domain92/servers/MS92_1/data/nodemanager/boot.properties, the following paths aresearched for the config_file_name:– /home/weblogic/bea/user_projects/domains/domain92/

– /home/weblogic/bea/user_projects/domains/domain92/config/

v The WebLogic launcher sensor configuration contains the following information:– The domain configuration directory.– The IP address on which the WebLogic administration console is listening.– The port number on which the WebLogic administration console is listening.See the topic “Configuring the sensor” for details.

On Windows, the WebLogic launcher sensor normally does not start if theWebLogic process is not started as a Windows service. It might start correctly if therequired environment variables have been set up.

On UNIX, when a non-typical installation has been performed, it might benecessary to set configuration information in the WebLogic launcher sensorconfiguration file.

For the WebLogic managed server, the WebLogic process name must be called withthe following argument:-Dweblogic.management.server=server_name

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


The sensor creates the following model objects:v app.AppConfigv app.AppServerv app.ConfigFilev app.j2ee.weblogic.WebLogicServerv app.j2ee.J2EEComponentv app.j2ee.J2EEDeployedObject


v app.j2ee.J2EEDomainv app.j2ee.J2EEModulev app.j2ee.J2EEResourcev app.j2ee.weblogic.WebLogicClusterv app.j2ee.weblogic.WebLogicConnectorv app.j2ee.weblogic.WebLogicConnectorModulev app.j2ee.weblogic.WebLogicDomainv app.j2ee.weblogic.WebLogicEJBModulev app.j2ee.weblogic.WebLogicJ2EEApplicationv app.j2ee.weblogic.WebLogicJDBCConnectionPoolv app.j2ee.weblogic.WebLogicJDBCDataSourcev app.j2ee.weblogic.WebLogicJDBCDriverv app.j2ee.weblogic.WebLogicJDBCMultiPoolv app.j2ee.weblogic.WebLogicJDBCTxDataSourcev app.j2ee.weblogic.WebLogicJMSServerv app.j2ee.weblogic.WebLogicJMSStorev app.j2ee.weblogic.WebLogicJTAv app.j2ee.weblogic.WebLogicMachinev app.j2ee.weblogic.WebLogicSSLSettingsv app.j2ee.weblogic.WebLogicServerv app.j2ee.weblogic.WebLogicServletv app.j2ee.weblogic.WebLogicVirtualHostv app.j2ee.weblogic.WebLogicWebContainerv app.j2ee.weblogic.WebLogicWebModulev app.ProcessPoolv app.SoftwareContainerv app.web.WebVirtualHost

Resources that the sensor discoversThis topic describes the resources that can be discovered by the WebLogicpluggable sensors, and how those discoveries work.

Information is gathered from XML configuration files on the target machine.WebLogic default properties are stored in an XSD schema, rather than XMLconfiguration files.

WebLogic launcher sensor

The WebLogic launcher sensor is started, after the generic server sensor, using apluggable template, configured in plugin.xml. It discovers most typical WebLogicinstallations, and can be manually configured if necessary.

It discovers the following information:v The path to the directory containing configuration files for the domain.v The version of WebLogic installed on the target machine.v Whether the target is an administration server or a managed server.v The listen IP and port of the administration server.v Basic information about the structure of the WebLogic domain and servers.


The WebLogic launcher sensor creates the following objects:v The WebLogic domain model object with only the attributes that are included in

the naming rule.v The WebLogic server model objects with only the attributes that are included in

the naming rule.

The WebLogic launcher sensor starts the following sensors:v WebLogic domain sensor for administration serverv WebLogic server sensor for administration server

WebLogic domain sensor

The WebLogic domain sensor discovers information about the full WebLogicdomain.

The following information (available in XML configuration files), is discovered:v Domain detailsv Machine detailsv Cluster detailsv SSL settingsv JTAv JDBC connection poolv JDBC data sourcev JDBC multi poolv JMS serverv Node manager settings

The WebLogic domain sensor creates the WebLogic domain object.

WebLogic server sensor

The WebLogic server sensor discovers information about the full WebLogic serverand basic information about the WebLogic domain.

The following information (available in XML configuration files), is discovered:v Server detailsv JDBC connection poolv JDBC data sourcev JDBC multi poolv JMS server

The WebLogic server sensor creates the WebLogic server model object.

The WebLogic server sensor starts the WebLogic application sensor.

WebLogic application sensor

The WebLogic application sensor discovers the WebLogic applications deployed onthe WebLogic server and the WebLogic applications deployed on the WebLogicdomain.


The following information about the deployment is stored:v Application or module, for example, J2EEApplication, EJBModule, WebModule,

or ConnectorModule.v Application or module details, including J2EEDeployedObjects, for example

WebLogicEntityEJB, WebLogicServlet, and WebLogicConnector.v Application subdeployment information.

Asynchronous and script-based discovery supportThe WebLogic SSH sensor supports asynchronous and script-based discovery.



For script-based discovery, you must configure the WeblogicLauncherSensor sensorto use script-based discovery. See the TADDM Administrator's Guide for informationabout configuring for script-based discovery. The following sensors, which aredescendants of the WeblogicLauncherSensor sensor, require no configuration:v WeblogicApplicationSensorv WeblogicDomainSensorv WeblogicServerSensor

Limitations

The last modification dates of collected configuration files are not available.


Configuring the sensorThe WebLogic pluggable sensors can be configured by editing the plugin.xmlconfiguration file.

You can perform WebLogic-specific configuration by editing the <configuration>element for the following WebLogic pluggable sensors:v WebLogic launcher sensorv WebLogic server sensorv WebLogic application sensor

WebLogic launcher sensor configuration

The plugin.xml file for the WebLogic launcher sensor is located in the$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.app.j2ee.weblogic.sensor.weblogiclaunchersensor_1.2.0directory.

Within the <configuration> element, you can configure information about theconfiguration directory for each domain. Place the information for each domain ina separate <item> element. For each domain, you can configure the followingelements:

<configDirectory>The domain configuration directory.


<adminServer>Contains information about the IP address and port number on which theWebLogic administration console is listening. The following elements areused to specify this information:

<listenAddress>The IP address on which the WebLogic administration console islistening.

<listenPort>The port number on which the WebLogic administration console islistening.

The following sample configuration file displays the typical usage of the<configuration> element, and its child elements:<configuration className="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicLauncherConfigurationItem"><domain><item><configDirectory>/opt/bea10/wl_10.0/domains/medrec/config</configDirectory><adminServer><listenAddress>127.0.0.1</listenAddress><listenPort>7011</listenPort></adminServer></item><item><configDirectory>/opt/bea/user_projects2</configDirectory><adminServer><listenAddress>127.0.0.1</listenAddress><listenPort>7002</listenPort></adminServer></item></domain></configuration>

You can also specify the location of the domain configuration directory by startingthe WebLogic server with the following argument:-Dpredefined.domain.config.dir=domain_directory

WebLogic server sensor configuration

The plugin.xml file for the WebLogic server sensor is located in the$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.app.j2ee.weblogic.sensor.weblogicserversensor_1.2.0directory.

In the plugin.xml configuration file, you can configure the following elements:

<discoverAppDescriptors>Specifies if the discovery of application descriptors is enabled. Thediscovery of application descriptors can be time consuming because thedescriptors are defined in additional configuration files on the remotemachine where WebLogic is installed.

<discoverJdbcDetails>Specifies if the discovery of JDBC descriptors is enabled. The discovery ofJDBC descriptors can be time consuming because the descriptors aredefined in additional configuration files on the remote machine whereWebLogic is installed.

The following sample configuration file displays the typical usage of the<discoverAppDescriptors> and <discoverJdbcDetails> elements:<configurationclassName="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicServerConfigurationItem"><discoverAppDescriptors>true</discoverAppDescriptors><discoverJdbcDetails>true</discoverJdbcDetails></configuration>


WebLogic application sensor configuration

The plugin.xml file for the WebLogic application sensor is located in the followingdirectory:$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.app.j2ee.weblogic.sensor.weblogicapplicationsensor_1.2.0

In the plugin.xml configuration file, you can configure the following elements:

<discoverApplicationDetails>Specifies if the discovery of application/module details is enabled. Thediscovery of application/module descriptors (J2EE descriptors) can be timeconsuming because the descriptors are defined in additional configurationfiles on the remote machine where WebLogic is installed.

The following sample configuration file displays the typical usage of the<discoverApplicationDetails> element:<configurationclassName="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicApplicationConfigurationItem"><discoverApplicationDetails>true</discoverApplicationDetails></configuration>

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

The sensor fails with a Domain config dir not found error

ProblemThe Domain configuration directory cannot be found. Check the ps outputfor the process and verify in the limitations section that the configuration issupported.

SolutionUse one of the following methods:v Run the WebLogic server using the argument

-Dpredefined.domain.config.dir=domain_directory or–Dweblogic.RootDirectory=domain_directory

v Configure the path to the domain administrator server in the WebLogiclauncher sensor configuration. See the topic “Configuring the sensor” fordetails.

WeblogicLauncherSensor fails because the ps output is cut onHP-UX

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

ProblemWeblogicLauncherSensor fails when trying to discover WebLogic onHP-UX and the following error message can be found in the sensor logfile: "Cannot find server name in command line: <COMMAND LINE>". Apossible reason of this failure is the cut of a ps command output, which isa documented behavior of HP-UX.

Solution


1. Setcom.ibm.cdb.discover.WeblogicLauncherSensor.parseConfigXml=truein collation.properties.

2. Restart TADDM and run the discovery again.

If extracting the server name from the command line fails,WeblogicLauncherSensor reads it from the local configuration file(config.xml).


Chapter 3. Database sensors

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

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


Db2Sensor and Db2WindowsSensor

Prerequisites

The sensor assumes the following prerequisites:v Discovery of the computer system must succeed.v DB2 must be installed in the instance owner's home directory.

Security issues

The DB2 user credentials must belong to the DB2 administration group.

Discovery is performed by using shell scripts that run the following DB2 utilityprograms on the remote system:v dist/bin/db2find.sh

v dist/bin/db2findschema.sh

The scripts run the following DB2 commands:

db2 Command line processor invocation command

db2ilistList instances command

db2set DB2 profile registry command

db2licmLicense management tool command

db2levelShow DB2 service level command

db2 get dbm cfg

Limitations

During discovery, the sensor temporarily changes the code page of the db2command-line tool. The sensor reverts the code page to its original setting after thediscovery is completed.

Incorrect characters can be discovered if you are using a 32-bit DB2 on a 64-bitWindows operating system. This character encoding problem is due to a limitationof the 64-bit Windows operating system, which hides commands such as chcp from32-bit applications such as the db2cmd.exe program.


If more than one version of DB2 is installed on the same Windows computersystem, the sensor cannot discover the IBM DB2 Universal Database (UDB) server.

TADDM runs the topology building process on a periodic basis. Until the topologybuilding process is complete after a discovery, the database names that aredisplayed for remote systems might not be unique. After the topology buildprocess is complete, the database name contains both the port number and the IPaddress of the remote database.


The sensor creates the following model objects:v app.db.db2.Db2AdminServerv app.db.db2.Db2Aliasv app.db.db2.Db2BufferPoolv app.db.db2.Db2ConfigValuev app.db.db2.Db2Containerv app.db.db2.Db2Databasev app.db.db2.Db2DatabaseConfigValuev app.db.db2.Db2Instancev app.db.db2.Db2InstanceConfigValuev app.db.db2.Db2Modulev app.db.db2.Db2Schemav app.db.db2.Db2Serverv app.db.db2.Db2ServerProcessv app.db.db2.Db2Systemv app.db.db2.Db2SystemConfigValuev app.db.db2.Db2TableSpace

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




Limitations

The following limitations apply:v For script-based discovery, the sensor requires database credentials. If these

credentials are not provided, the sensor completes with the following error:No system detected

v Discovery of application descriptors is not supported.




To configure the access list, complete the following steps:1. Select Database as the Component Type.2. Select DB2 as the Vendor.3. Specify the following required information:


The DB2 UNIX sensor uses credentials from the access list in the followingsequence:1. The sensor searches the access list looking for the DB2 user credentials.

This is the owner of the current DB2 instance.2. If step 1 fails, the sensor attempts to connect to DB2 using each DB2 user

credential from the access list.3. If step 2 fails, the sensor attempts to connect using the Computer System user

credentials (using user credentials from the Computer System access list).

For discovery of multiple DB2 installations on a single machine: DB2, the usercredentials from the access list must belong to the DB2 administration group for allDB2 installations.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the IBM DB2 sensor uses.

The DB2 sensor that is running on a Windows system (Db2WindowsSensor) usesthe following property:

com.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout=300000

The default value is 300000. The value must be an integer.

This property specifies the maximum amount of time (in milliseconds) thatthe DB2 sensor can run on a Windows system.

To be effective, the value of this property should be:v Greater than the value of the com.collation.SshSessionCommandTimeout

property, which controls the time that is allowed for the SSH commandto run on the Windows gateway. If the value of theDb2WindowsAgent.sshSessionCommandTimeout property is less than thevalue of the com.collation.SshSessionCommandTimout property, thecom.collation.SshSessionCommandTimout value is used.

v Less than the value of the com.collation.discover.DefaultAgentTimeoutproperty. Because the sensor can stop before it finishes collectinginformation, the value of thecom.collation.discover.DefaultAgentTimeout property should begreater.

If needed, you can change the values of thecom.collation.SshSessionCommandTimeout andcom.collation.discover.DefaultAgentTimeout properties.

Chapter 3. Database sensors 133

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

com.collation.discover.agent.DB2Agent.db2findscript=sudoThis value enables access to the dist/bin/db2find.sh script executedduring the discovery using the sudo command.

com.collation.discover.agent.DB2Agent.db2findschemascript=sudoThis value enables access to the db2findschema.sh script executed duringthe discovery using the sudo command.

com.collation.discover.agent.DB2Agent.systemcommand=sudoThis value enables access to the system command executed during thediscovery using the sudo command.

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

The DB2 sensor fails during discovery

ProblemThe DB2 sensor is timing out during the discovery run.

SolutionIncrease the com.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout property in the collation.properties file. Also, youcould increase the com.collation.discover.DefaultAgentTimeout propertyto ensure that it is always larger than thecom.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout property.

Dependencies exist between a database and a businessapplication but are not detected

ProblemAlthough dependencies exist between a database and a businessapplication, no dependency is detected because the user that is defined inthe discovery access list for DB2 is not the instance owner.

SolutionFor discovery processes to find the DB2 commands to list databases, theuser that is defined in the discovery access list for DB2 must source theDB2 profile in the user profile.

The Details panel for a discovered DB2 component is blank

ProblemWhen performing a discovery, the Details panel under the License tab for adiscovered DB2 component is blank. This problem affects all levels ofTADDM, on all platforms.

SolutionOn UNIX and Linux, the db2licm executable routine must have the properpermissions for the user specified in the Discovery Management Consoleas connecting to the database. To retrieve the license information, theDiscovery user must also have the primary group of the DB2 instanceowner in its group list.


CTJTP1127E The copy command fails during a DB2 discovery

ProblemThe following error message is displayed in the Discovery ManagementConsole during a discovery of DB2:CTJDT0234E The following error occurred:CTJDT0235E The following erroroccurred when running the DB2 discovery script (db2find.sh):sh coll/bin/db2-db2find.sh.

Additionally, the following information is displayed in the DB2 sensor log:com.collation.discover.agent.AgentException: CTJDT0235E The following erroroccurred when running the DB2 discovery script (db2find.sh): sh coll/bin/db2-db2find.sh.at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.runDb2Find(Db2Sensor.java:414)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.findSystems(Db2Sensor.java:275)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.discover(Db2Sensor.java:212)at com.collation.discover.engine.AgentRunner.run(AgentRunner.java:131)at com.collation.discover.engine.DiscoverEngine.processWorkItem(DiscoverEngine.java:1247)at com.collation.discover.engine.DiscoverEngine$DiscoverWorker.run(DiscoverEngine.java:816)Caused by:com.collation.platform.session.SessionClientException: CTJTP1127E The copycommand failed for java.io.EOFException: SSHSCP1: premature EOF.at com.collation.platform.session.Ssh2SessionClient.copyToRemote(Ssh2SessionClient.java:441)at com.collation.platform.session.Ssh2SessionClient.copyToRemote(Ssh2SessionClient.java:397)at com.collation.platform.session.SessionClientPool.copyToRemote(SessionClientPool.java:236)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.prepareScript(Db2Sensor.java:726)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.runDb2Find(Db2Sensor.java:383)... 5 more

SolutionThis error message appears because the secure copy (scp) command is notin the PATH of the user ID that is being used by the remote computersystem to discover DB2.

To correct this problem, edit or create a file called environment in<taddmusr>/.ssh on the remote computer system that is being discovered.Define the <taddmusr> PATH environment variable in this file. Make surethat you include the full path to the scp command in the PATHenvironment variable.

The DB2 sensor fails with error CTJTD0234E

ProblemThe DB2 sensor fails with error CTJTD0234E and the following errormessage:Attribute not set: instances

SolutionThis message is displayed because the PATH variable does not include theDB2 commands needed by the db2find.sh script.


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

IBM Informix sensorThe IBM Informix sensor discovers IBM Informix Dynamic Servers.


Informix

Prerequisites

The IBM Informix JDBC driver must be installed on the IBM Informix DynamicServer.

Limitations

The Informix Dynamic Server must be configured with the minimum requirementfor discovery. Add the discovery service account to the group Informix on theInformix Dynamic Server.

Model objects with associated attributesThe IBM Informix sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about IBMInformix Dynamic Server resources in your IT environment.


app.db.ids.IDSAlias

v AliasNamev Parentv Protocolv ServiceName

app.db.ids.IDSBufferPool

v BufferPoolIDv NumBuffersv Size

app.db.ids.IDSChunk

v ChunkNumberv FreeSpacev Offsetv Sizev MirrorOffsetv Parent

app.db.ids.IDSConfigValue

v ConfigIDv ConfigName


v DefaultValuev EffectiveValuev OriginalValue

app.db.ids.IDSDatabase

v DatabaseLocalev LoggingTypev Name

app.db.ids.IDSInstance

v BitSizev ConnectOptionv Homev Hostv Namev ProductNamev ProductVersionv OnConfigv Protocolv SQLHostFilev Statusv VersionString

app.db.ids.IDSSegment

v OS_SHM_ADDRv OS_SHM_IDv OS_SHM_KEYv SegmentClassv Size

app.db.ids.IDSServerProcess

v OSProcessNamev PIDv VpClassv VpID

app.db.ids.IDSSpace

v Chunksv ObjectTypev PageSizev SpaceNamev SpaceNumber

app.db.ids.IDSStartupEnvironmentVar

v StartupEnvVarNamev StartupEnvVarValue

Configuring the access listTo give the IBM Informix sensor access to the Informix Dynamic Server, you mustconfigure the access list.



contains the IP address of the Informix Dynamic Server.2. To create an access list, click the Access List icon.3. In the Access List window, click Add.4. In the Component Type field of the Access Details window, click

ComputerSystem.5. Type the credentials to access the target Informix Dynamic Server. TADDM uses

JDBC to connect to the Dynamic Server.

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

Sensor cannot retrieve server information

ProblemThe sensor cannot retrieve information as the Informix Dynamic Server isnot started.

SolutionEnter the oninit command to start the database server.

Message states that nothing exists to be discovered

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

SolutionNo active Informix instance is running on the target computer system.

TADDM cannot connect to an Informix database

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

SolutionEnsure that the connection from the TADDM server to the Informix porton the database server is open.

Microsoft SQL Server sensorThe Microsoft SQL Server sensor discovers Microsoft SQL Servers.


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:


v sysdatabasesv syscurconfigsv sysprocessesv sysobjectsv syscolumns

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


The sensor creates the following model objects:v db.mssql.SqlServerv db.mssql.SqlServerConfigv db.mssql.SqlServerDatabasev db.mssql.SqlServerModulev db.mssql.SqlServerProcess


Configuring authentication methodsThere are two modes of authentication that TADDM can use to discover an SQLServer.

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 WMIProvider on all target Windows systems during the discovery process.

Discovering a SQL Server requires that the Windows Server must be discoverable,but also requires that additional access is granted to TADDM.

There are two modes of authentication that TADDM can use to discover an SQLServer:

Windows authenticationFor Windows authentication, you must meet the following requirements:v The Windows user used for the discovery of 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 authenticationFor SQL mode authentication, .NET is used to connect to the SQL Serverwithout having to logon to the Windows Server. You must meet thefollowing requirements:


v Add the Windows user and password to the access list for the Windowscomputer 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 SQLServer administrator which mode the SQL Server is running. Mixed mode supportsboth types of authentication.


The TADDM SQL auth list only applies to SQL authorization (and not Windowsauthorization).

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:


For SQL discovery using Windows authorization, TADDM requires that theWindows 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 canaccess 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 entriesThis topic lists the collation.properties file entries that the Microsoft® SQLServer sensor uses.

Microsoft® SQL Server sensor uses the following sensor settings:

com.collation.discover.agent.SqlServerAgent.UseListeningIpThis value specifies how the display names for SQL server instance objectsare generated.

When the property value is false, the display names for the SQL serverinstance objects take the following form: host_fqdn + ":" +sql_server_instance_port_number

When the property value is true, the display names for the SQL serverinstance objects take the following form: sql_server_listening_fqdn + ":" +sql_server_instance_port_number

The default value is false.

com.collation.discover.agent.SqlServerAgent.timeoutThis value specifies the length of time, in milliseconds, that the sensor runsbefore timing out.


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

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

No details available for SQL Server after discovery

ProblemSQL Server is discovered but there are no details provided.

SolutionCheck that the SQL Server authorization has access to the system tables,such as sysdatabases, systables, and so on. If an SQL Server authorizationis not used, check the Windows authorization.

Microsoft SQL discovery without datareader authority

ProblemIs it possible to discover a Microsoft SQL database without having to grantthe required db_datareader role to the entire database.

SolutionTo discover a Microsoft SQL database, without having to grant authority tothe entire database, use the following steps:v Create a user using the storage procedure from the SQL Server.v Use the sp_addlogin command to create a 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 thefollowing example the user is taddmusr:GRANT SELECT on sysdatabases to taddmusr;GRANT SELECT on syscurconfigs to taddmusr;GRANT SELECT on sysprocesses to taddmusr;GRANT SELECT on sysobjects to taddmusr;GRANT SELECT on syscolumns to taddmusr;

ProductName attribute is not clear

ProblemThe ProductName attribute does not present enough information about theproduct.

SolutionIf you recently migrated from the previous TADDM version, you mustrediscover the Microsoft SQL Servers. The attribute includes the SQLServer version number, the ServicePack level, and the SQL Server edition.

The ProductName attribute has the following form:v Microsoft SQL Server 2008 R2 SP1 (Enterprise Edition)


Oracle sensorThe Oracle sensor discovers Oracle Database servers.


OracleSensor

Prerequisites

The following requirements must be met:v Discovery of the computer system must succeed.v Network connectivity between the TADDM server and the Oracle Listener must

be functioning.

Security issues

The Oracle user credentials used to discover an Oracle database from TADDM,must have execute privileges. To ensure that the correct privileges are granted tothe Oracle user, run the following command: grant execute on dbms_system tooracle_user;

The Oracle database account requires CONNECT privileges.

The Oracle access list user must have the following role:SELECT_CATALOG_ROLE.

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 supportThe Oracle sensor supports asynchronous and script-based discovery.






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 anonscript-based discovery. Complete the following steps:1. Select Database as the component type.2. Select Oracle as the vendor.


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

Limitations

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

The following functions are not supported:v Application descriptor discoveryv Oracle RAC discoveryv Oracle ASM discoveryv Raw schema discovery (the list of tables in the database is limited)v OracleDBLink model object discoveryv OracleListener model object discovery

Model objects with associated attributesThe Oracle sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about configuration itemsin the Oracle environment.


OracleASMAsmInstances

DiskGroups

Name

Node

Rac

OracleASMDiskAsmDiskGroup

State

Name

OracleASMDiskGroupAsm

AsmDisks

Name

State

OracleASMInstanceBackgroundProcesses

Database

Host

Hostname

OracleInstanceStatus


Parameters

Parent

Port

RacDatabase

SGAValues

SID

ServerProcesses

OracleBackgroundProcessDescription

Name

Pid

OracleControlFileName

OracleDBLinkIpAddress

Port

ServiceName

OracleDataFileName

Size

TableSpace

OracleDatabaseControlFiles

DBName

DBVersion

DataFiles

InitValues

Name

RedoLogFiles

SchemaRawData

Schemas

TableSpaces

OracleInitValueDescription

Name

Value

OracleInstanceBackgroundProcesses

ConfigContents

Database


Host

KeyName

Modules

Name

Port

PrimarySAP

ProcessPools

ProductName

ProductVersion

SGAValues

SID

ServerProcesses

Status

OracleListenerBindAddresses

Name

OracleModuleFileName

Name

Schema

OracleRACAsm

HomePath

Name

OCRLocation

PrimaryNode

RacDatabases

VoteDiskPath

OracleRedoLogFileName

Size

OracleSGAValueName

Value

OracleSchemaName

Owner

OracleServerConfigFile

Listeners


OracleServerProcessConnections

Name

PID

Ports

OracleTableSpaceName

Size

ProcessPoolName

RuntimeProcesses



To configure the access list, complete the following steps:1. Select Database as the Component Type.2. Select Oracle as the Vendor.3. Specify the following required information:

a. User nameb. PasswordTo discover Oracle Automatic Storage Management (ASM) file systems, typethe user name sys and password.


com.collation.discovery.oracle.extendedThis property specifies whether additional configuration values aboutOracle database links are stored.

The default value is N (No).

If you set the property to Y (Yes), the sensor stores additional configurationvalues about Oracle database links.




You must set this property to true if you want to discover an OracleApplication Server or the WebLogic sensors. For example, if the


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

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

Oracle sensor does not start

ProblemThe Oracle signature is not matching because either you have renamed theOracle binaries or you are running a version of the Oracle server thatTADDM does not support (Express® Edition, for instance).

SolutionDo not change the names of the binaries and ensure you are using asupported version of Oracle. Also make sure that the TNSListener serviceis started for the Oracle database.

Sensor fails with “Unable to find the servers” error

ProblemThe Oracle database account is not functioning because of one of thefollowing reasons:v The password is not correct.v The account is locked.v The account does not have connect privileges.

SolutionUpdate the access list, unlock the account, or add the connect privilege.

From the command prompt, test the account by running the sqlpluscommand, as shown in the following example:bash-2.05b$ sqlplus

SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jun 12 08:15:23 2007Copyright (c) 1982, 2005, Oracle. All rights reserved.Enter user-name: systemEnter password:ERROR:ORA-28000: the account is locked

Sybase sensorThe Sybase sensor discovers Sybase Adaptive Server Enterprise (ASE) databaseservers.


SybaseSensor

Security issues

To assign the minimum privileges to the Sybase discovery user, run the followingcommand:grant select on sysengines from public

The following tables are queried:


v versionv master..sysconfiguresv master..sysusagesv master..syssegmentsv master..sysprocessesv master..sysenginesv master..sysdatabasesv master..sysdevicesv master..syscurconfigsv master..sysserversv master..syssrvrolesv master..sysloginsv master..sysloginrolesv master..syspartitionsv master..systhresholdsv master..sysresourcelimitsv master..systimeranges

Limitations

The Sybase sensor does not collect information about schemas owned by the dbouser.

Model objects with associated attributesThe Sybase sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about storage resources inyour IT environment.


AppConfig

v Contentv Parent

ConfigFile

v FixedPathv RealFilev URI

LogicalContentFixedPath

ProcessPool

v CmdLinev Envv Namev Parentv RuntimeProcesses

SybaseConfigValue


v ConfigUnitv Namev Parentv RunValuev Typev Value

SybaseDatabase

v Namev Optionsv Ownerv Parent (SybaseServer)v SchemasRawDatav Segmentsv Tablesv Thresholdsv Users

SybaseDevice

v Descriptionv FirstVirtualPageNumberv FixedPathv IsDefaultDiskv IsDeviceMirroredv IsDsyncEnabledv IsDumpDevicev IsMasterDeviceMirroredv IsMirrorEnabledv IsPhysicalDiskv IsReadsMirroredv IsSecondaryMirrorSideOnlyv IsSerialWritesv IsSkipHeaderv LastVirtualPageNumberv MirrorPathv Parent (SybaseServer)v RealFilev URI

SybaseEngineProcess

v CmdLinev Namev PIDv Parentv Ports

SybaseLogin

v AccumulatedDate


v FailedLoginCountv FullNamev IsAccountLockedv IsPasswordExpiredv Languagev Namev Parent(SybaseServer)v PasswordDatev SybaseRolesv TotalCPUUsedv TotalIOUsed

SybaseModule

v Databasev FileNamev Namev Parent

SybaseRemoteServer

v IsMessageConfidentialv IsMessageIntegrityv IsMutualAuthenticationv IsNetworkPasswordEncryptedv IsReadOnlyv IsRPCSecurityModelBv IsTimeoutEnabledv Namev NetworkNamev RemoteNetworkCostv RemoteServerClassv SybaseServer

SybaseResourceLimitation

v AppNamev IsEnforcedDuringExecutionv IsEnforcedPriorToExecutionv LimitationExceededActionv LimitationScopev LimitTypev LimitValuev Loginv Namev Parent (SybaseServer)v TimeRange

SybaseRole

v FailedLoginCountv Name


v Parentv PasswordDatev Status

SybaseSegment

v Namev Parentv Size

SybaseServer

v BindAddressesv ConfigContentsv ConfigFilev ConfigValuesv Databasesv Devicesv EngineProcessesv FullVersionv Homev Hostv KeyNamev Loginsv Modulesv Namev PrimarySAPv ProcessPoolsv ProductNamev ProductVersionv RemoteServersv ResourceLimitationsv ServerProcessesv Statusv SybaseRolesv TimeRanges

SybaseServerProcess

v Namev PIDv Parent

SybaseTable

v CreationDatev Namev Parent(SybaseDatabase)v Partitions

SybaseTablePartition

v FirstPagev NumPages


v Parent (SybaseTable)v PartitionID

SybaseThreshold

v IsLastChancev Namev Parent (SybaseDatabase)v Segmentv ThresholdExeededProcedurev ThresholdSizev User

SybaseTimeRange

v EndDayv EndTimev Namev Parent (SybaseServer)v StartDayv StartTime

SybaseUser

v Loginv Namev Parent (SybaseDatabase)


To configure the access list, complete the following steps:1. Select Database as the Component Type.2. Select Sybase as the Vendor.3. Specify the access information (user name and password) that TADDM should

use to establish a JDBC connect to the Sybase server.

Sybase IQ sensorThe Sybase IQ sensor discovers Sybase IQ database servers.


SybaseIQSensor

Security issues

To assign the minimum privileges to the Sybase discovery user, run the followingcommand:grant execute on sp_iqdbsize



The sensor creates the following model objects:v app.AppConfigv app.ConfigFilev app.db.sybase.SybaseConfigValuev app.db.sybase.SybaseDatabasev app.db.sybase.SybaseDevicev app.db.sybase.SybaseEngineProcessv app.db.sybase.SybaseModulev app.db.sybase.SybaseServerv app.ProcessPoolv core.LogicalContent


To configure the access list, complete the following steps:1. Select Database as the Component Type.2. Select Sybase as the Vendor.3. Specify the access information (user name and password) that TADDM should

use to establish a JDBC connect to the Sybase server.


Chapter 4. Generic sensors

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

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


AnchorSensor

Prerequisites

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



The TADDM server uses SSH to communicate with the remote anchor server. Toconfigure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM must

use for either SSH key-based authentication or SSH login-based authenticationto the remote anchor server.

Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process can require privilegeescalation (typically done using the sudo command).

For more information, see the topic “Commands that might require elevatedprivilege” in the “Administering” topics in the IBM Tivoli Application DependencyDiscovery Manager information center.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Anchor sensor uses.


com.collation.discover.agent.AnchorSensor.timeout=3600000Specifies the time allowed to start a new anchor server.

com.collation.discover.anchor.forceDeployment=trueSpecifies if all anchors for the discovered scope are to be deployed duringdiscovery startup. Valid values are true and false. The default is true. If you


change the default to false, anchors are deployed only if any IP addressfrom the scope cannot be pinged, or if port 22 cannot be reached on any ofthe discovered IP addresses.

com.collation.discover.anchor.lazyDeployment=falseSpecifies if files must be copied during anchor deployment, or when thesensor requiring the files is going to be launched. In both cases onlydifferent files are copied. Valid values are true and false. The default is false.

The following example provides some insight to how this property affectsTADDM functionality:

The WebSphere Application Server sensor has dependencies in thedist/lib/websphere directory which are 130 MB in size. If the flag is set tofalse, this data is copied to the target host when the anchor is deployed. Ifthe flag is set to true, the data is copied when the WebSphere ApplicationServer sensor is about to be run on the anchor. If no WebSphereApplication Server sensor is run through the anchor, 130 MB is not sent tothe remote host.

com.collation.discover.anchor.connectType=sshSpecifies whether to connect to the anchor using a ssh tunnel or a directsocket. Valid values are ssh and direct. The default is ssh. To specify theconnection type for a particular address, usecom.collation.discover.anchor.connectType.1.2.3.4=ssh, where 1.2.3.4 isthe address for which you want to specify the connection type.

com.collation.platform.session.GatewayForceSshSpecifies whether to force the gateway to act independently of the anchor.Valid values are true and false. Set the value to true to resolve Cygwinissues when both the gateway and anchor are on the same system. Whenthe value is set to true, an SSH session is used to transfer traffic betweenthe gateway and anchor rather than a local session.

Asynchronous discovery sensorThe asynchronous discovery sensor is required for asynchronous discovery. IPaddresses that are unreachable (cannot be pinged) are candidates for asynchronousdiscovery. The asynchronous discovery sensor attempts to determine which of theunreachable IP addresses are valid.

The TADDM Administrator's Guide contains information about asynchronousdiscovery, including how to configure for asynchronous discovery.

In asynchronous discovery, the output of the discovery script is an archive file thatcontains the discovery results and is stored in a directory on the TADDM server.An unreachable IP address is considered valid if an archive file exists on theTADDM server for that IP address. Based on the content of the archive file, theappropriate sensors are scheduled to process their discovery script output. Sensorsthen perform discovery by parsing the script output instead of directly accessingthe target system, as is done in a nonscript-based discovery.


ASDSensor


Configuring the sensor

The asynchronous discovery sensor does not use the access list.

The asynchronous discovery sensor uses the following entries in thecollation.properties file:v com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectoryv com.ibm.cdb.discover.asd.ProcessUnreachableIPsv com.ibm.cdb.tarpath

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


ASDPingSensor

Prerequisites

In a discovery profile, if you are using the asynchronous discovery ping sensor,you must disable the ping sensor because you cannot enable both of these sensorsin a discovery profile.

Custom application server sensorThe custom application server sensor creates a custom application server that isbased on template and runtime process information that is discovered by thegeneric server sensor. The sensor also collects configuration files or applicationdescriptors if these are specified in the template and performs extension processingto collect additional information.



Prerequisites

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

Limitations

See the limitations for the generic server sensor.


The following model objects are used to create generic AppServers:v app.AppServerv app.db.DatabaseServerv app.j2ee.J2EESever

Chapter 4. Generic sensors 157

v app.web.WebServer

The following model objects are used to extend TADDM application sensors:v app.db.db2.Db2Serverv app.db.mssql.SqlServerv app.j2ee.jboss.JBossServerv app.j2ee.weblogic.WebLogicServerv app.j2ee.websphere.WebSphereServerv app.messaging.exchange.ExchangeServerv app.messaging.mq.MQQueueManagerv app.sms.SMSiteServerv app.veritas.cluster.VCSClusterv app.web.apache.ApacheServerv app.web.iis.IIsWebServerv app.web.iplanet.IPlanetServer

Custom MIB2 computer system sensorThe custom MIB2 computer system sensor creates a custom computer system thatis based on template information.

This template information is matched for one or more of the following items:v system OID (SNMPv2-MIB::sysObjectID - .1.3.6.1.2.1.1.2)v system Description (SNMPv2-MIB::sysDescr - .1.3.6.1.2.1.1.1) discovered by the

SNMP MIB2 sensor

The custom MIB2 computer system sensor performs extension processing to collectadditional information.



Limitations

See the limitations for the SNMP MIB2 sensor.


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

Generic computer system sensorThe generic computer system sensor discovers the type of a computer system. Theresults of this sensor are used to start a specific computer system sensor, such asthe Linux computer system sensor.




Generic server sensorThe generic server sensor discovers the application servers that are running on ahost computer system.

The sensor first discovers listening ports (IP address and ports), establishedconnections, and processes that are running on targeted computer systems.Templates are used to match runtime process information. When specified criteriaare matched, the information is used to seed specific application sensors, such asthe Apache sensor or a custom application server sensor.

The processes can be running on IPv4 or IPv6 addresses. For processes that arerunning on IPv6 only, the processes are discovered, but a seed that starts a morespecific sensor is not created.

Custom server templates are used to discover application servers that TADDMdoes not automatically categorize. You can create custom server templates usingthe Discovery Management Console. If multiple custom server templates match theapplication runtime process information, only the first custom server template thatis matched causes the custom application server sensor to run.


GenericServerSensor

Limitations

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


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

Asynchronous and script-based discovery supportThe generic server sensor supports asynchronous and script-based discovery.








Limitations

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

On Solaris operating systems that support virtualization, from the global zone, thegeneric server sensor does not support the discovery of runtime processes in localzones.






com.collation.discover.agent.command.netstat.Windows

You can use this property to specify a custom command to use instead ofthe netstat -nao command on a Windows target.

You must ensure that any alternative command you specify returnsinformation in the same format as the netstat -nao command.

For example,com.collation.discover.agent.command.netstat.Windows.ip_address=type c:\\\\folder\\\\mynetstat.txt

where mynetstat.txt contains the output of the netstat -nao command,and the type command is used to print the contents of the file.

IBM Tivoli Utilization sensorThe IBM Tivoli Utilization sensor gathers basic metrics from a target system. Thesensor uses the TADDM discovery infrastructure to deploy scripts that runsystem-level performance monitoring commands on the target system. At specifiedintervals, the sensor gathers data from the target system and provides it to theTADDM server, where operating system metric objects are created.

The IBM Tivoli Utilization sensor provides metrics and a utilization report. You canuse this information with the System Connection Topology Report to identifyservers that are not used to capacity and do not provide services to other servers.


OperatingSystemUtilizationSensor


Prerequisites

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

On target systems that are running the following operating systems, the followingrespective prerequisites must be met:v Linux

– The compress command must be available.– The netstat command must be available.– The sar command must be available.– The sadc command must be available.

v Solaris– The compress command must be available.– The netstat command must be available.– The sar command must be available.

v AIX– The compress command must be available.– The netstat command must be available.– The sar command must be available.– To run the sar command, the TADDM service account must be part of the

adm group.v HP-UX

– The compress command must be available.– The netstat command must be available.– The sar command must be available.– To schedule cron and at jobs, the TADDM service account must be added to

the cron.allow and at.allow files.

Limitations

The sensor is intended for short-term use (for example, a maximum of one monthof use) to analyze servers and identify consolidation targets. The sensor can beused only for the firewall zone in which the TADDM server resides. The use of ananchor server is not supported.

Over a longer period of time, for determining server availability, performance, andutilization, or for discovering applications that span firewall zones, use the IBMTivoli Monitoring product.

Asynchronous and script-based discovery supportThe IBM Tivoli Utilization sensor supports asynchronous and script-baseddiscovery. All function that is provided by the sensor during a nonscript-baseddiscovery is supported in an asynchronous or script-based discovery.



For asynchronous discovery, first complete the steps that are described in theTADDM Administrator's Guide in the section about configuring for asynchronousdiscovery. Before running an asynchronous discovery, you must start theUtilization sensor on the target system to collect utilization data. The discoveryscript package that is generated for an asynchronous discovery must be extractedon the target system. After the discovery script package is extracted, complete thefollowing 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 tocollect data, you must wait until after the time interval has elapsed.

4. Periodically collect data by running the taddmasd/scriptsRunner.sh script. Thisscript generates an archive file that contains the utilization data.

5. Move the resulting archive file to the TADDM server.6. Create a new asynchronous discovery profile for the Utilization sensor, enable

the sensor, and run an asynchronous discovery.7. When the collection of utilization data is complete, to stop the Utilization

sensor, change to the taddmasd/com.ibm.cdb.discover.sensor.sys.utilization_7.2.0 directory, and run thefollowing command:./utilizationDeployer.sh -u





Model objects with associated attributesThe IBM Tivoli Utilization sensor creates model objects with associated attributes.The attributes indicate the type of information that the sensor collects about theutilization of your Computer Systems in your IT environment.


metric.OperatingSystemMetric

v Labelv MetricNamev MetricUnitOfMeasurev MetricValuev StatisticName


net.IpInterface

v IpAddress

relation.Gauges

v Source (OperatingSystemMetric)v Target (OperatingSystem)

The following computer system types are discovered:

sys.aix.AixUnitaryComputerSystemsys.hpux.HpUxUnitaryComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.SunSPARCUnitaryComputerSystemsys.windows.WindowsComputerSystem

The following attribute is associated with these model objects:v signature

The following operating system types are discovered:

sys.aix.Aixsys.hpux.HpUxsys.linux.Linuxsys.sun.Solarissys.windows.WindowsOperatingSystem

The following attribute is associated with these model objects:v OSName

Configuring the sensorBefore running the IBM Tivoli Utilization sensor to gather data from a targetmachine, you must configure the sensor.

Setting configuration parametersYou can configure the behavior of the IBM Tivoli Utilization sensor by setting theconfiguration parameters.

The following table lists the configuration parameters of the IBM Tivoli Utilizationsensor.


Table 8. Configuration parameters

Parameter name Description

operatingMode The mode of operation for the sensor. The following values are valid:

ONCE Specifies that the collection scripts run once for the intervaland numDays, or maxFileSize, specified, whichever comes first.When the collection scripts have finished, the data is collectedby the sensor the next time that it runs. The data collected isparsed and stored on the TADDM database. All output files onthe target machine are cleaned up.

RESTARTSpecifies that when the collection scripts finish as normal, thecollection scripts are started again.

CLEANUPSpecifies that any collection currently running on the system isimmediately stopped and cleaned up. Once a cleanupoperation is called, collection can only be restarted on thismachine by setting the operatingMode value to RESTART.

collectionMode The mode of collection for the sensor. The following values are valid:

ALWAYSSpecifies that data is collected each time the sensor is run onthe target system, regardless of whether the collection scriptshave completed or not.

END Specifies that data is collected when the sensor is run on thetarget system, only if the collection scripts have completed.Except in situations where operatingMode is set to CLEANUP,any discovery performed before the collection scripts havecompleted results in no data collection.

interval The collection interval, in minutes, for collection scripts running on thetarget. Valid values are between 3 minutes and 60 minutes.

numDays The number of days that the collection scripts run on the target. Validvalues are between 1 day and 35 days.

maxFileSize The maximum size, in MB, for the output files created by the collectionscripts. Valid values are between 1 MB and 100 MB.

Configuring cleanup optionsThe IBM Tivoli Utilization sensor has a function that automatically cleans up andremoves the collection scripts and data stored on the target machine. It is alsopossible to perform the cleanup manually, if required.

Configuring automatic cleanup during discovery

To use the automatic cleanup function, complete the following steps:1. Create a profile configuration for the IBM Tivoli Utilization sensor that has the

operatingMode parameter set to CLEANUP.2. Run a discovery using the profile that has the CLEANUP option set.

After the cleanup has been performed on the target discovery machine, to start thecollection scripts again carry out a RESTART operation.


Performing manual cleanup

To perform a manual cleanup on a UNIX target machine, complete the followingsteps:1. Navigate to the /var/tmp/ directory.2. Run the following command:

./scmd_perf.sh -k -c -r

3. Remove the IBM Tivoli Utilization sensor lock file.

To perform a manual cleanup on a Windows target machine, complete thefollowing steps:1. Navigate to the C:\ directory.2. Remove the WINTEL-MAN-PERF.VBS script.3. Remove the PerformanceData_hostname.out file.4. Remove the IBM Tivoli Utilization sensor lock file.

Configuring the BIRT reportYou can use Utilization BIRT report to generate reports based on the data collectedby the IBM Tivoli Utilization sensor.

Procedure

To configure the Utilization BIRT report complete the following steps in the DataManagement Portal:1. Click Analytics > BIRT Reports. The TADDM BIRT Reports window is

displayed.2. Select TADDM_SERVER_UTILIZATION report and click Run Report.3. In the Parameter window, a value for each of the following parameters must be

specified:

Scope From the list of available TADDM scopes, select a scope.

Metric From the list of available metrics, select the metric for which you wantto view data, or select ALL to display data for all metrics.

OperatorOperators are used to restrict the data displayed in the report. From thelist of available operators, select an operator, or select N/A to displayall data for the selected metric.

Value If you specified an operator, you must specify a corresponding value.Otherwise, select N/A to display all data for the selected metric.

Another valueIf you specified an operator, and it requires two values, you mustspecify a corresponding value for the second value. Otherwise, selectN/A to display all data for the selected metric.

Number of application dependenciesThe number of application dependencies is used to restrict the datadisplayed in the report. Specify the number of applicationdependencies, or select N/A to display all data for the selected metric.

4. Click OK. The report output is displayed in the BIRT Report Viewer.


What to do next

To configure the Hourly Peak Server Utilization BIRT report complete thefollowing steps in the Data Management Portal:1. Click Analytics > BIRT Reports. The TADDM BIRT Reports window is

displayed.2. Select TADDM_SERVER_UTILIZATION_HOURLY_PEAK report and click

Run Report.3. In the Parameter window, a value for each of the following parameters must be

specified:

Scope From the list of available TADDM scopes, select a scope.

Date From the list of available dates, select a date.4. Click OK. The report output is displayed in the BIRT Report Viewer.

Configuring the discovery profileThe IBM Tivoli Utilization sensor is configured through the use of discoveryprofiles. A default discovery profile, named Utilization Discovery, is provided outof the box. It can be used to perform discoveries as is, or a new profile withcustomized configuration parameter values can be created.

The out-of-the-box Utilization Discovery profile has the following default propertyvalues:v operatingMode: ONCEv collectionMode: ALWAYSv interval: 15v numDays: 35v maxFileSize: 100

It contains the following default sensors:v Ping sensorv Port sensorv Session sensorv Anchor sensorv Operating system utilization sensor

If the default discovery profile is not sufficient for your needs, you can create aprofile with customized configuration parameters. To create a customizeddiscovery profile, complete the following steps:1. In the Discovery drawer of the Discovery Management Console, click

Discovery Profiles.2. In the Discovery Profiles window, click New.3. In the Profile Name field, type the name of the new profile.4. In the Description field, type a description of the new profile.5. From the Clone existing profile list, select Utilization Discovery.6. Click OK.7. In the Discovery Profiles window, select the new profile, and on the Sensor

Configuration tab, select the OperatingSystemUtilizationSensor sensor.8. To create a sensor configuration based on the

OperatingSystemUtilizationSensor default configuration, click New. TheCreate Configuration window is displayed.


9. In the Name field, type the name of the new sensor configuration.10. In the Description field, type a description of the new sensor configuration.11. Click Enable this configuration and disable selected configuration to ensure

that this configuration is used, by default, by the discovery profile.12. For each configuration parameter you want to update, complete the following

tasks:a. In the Configuration section, double click the configuration parameter you

want to change.b. Enter a new value for the configuration parameter.

13. Click OK.14. In the Discovery Profiles window, click Save.

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

Discovery using cleanup fails when using non-root credentials

ProblemA Utilization sensor discovery using the CLEANUP option fails for anendpoint when using non-root credentials.

SolutionIf the endpoint was last discovered by a TADDM server using rootcredentials, the Utilization sensor scripts deployed to /var/temp have rootsystem access. These scripts cannot be removed by the non-root user ID. Toensure that the cleanup completes correctly, run the Utilization sensordiscovery, using the CLEANUP option, on that endpoint, using rootcredentials. Any existing Utilization sensor scripts are removed.

Metrics data not discovered from a target machine when runningan asynchronous discovery

ProblemAn asynchronous discovery is run, but the IBM Tivoli Utilization sensordoes not discover metrics data on the Solaris operating system.

SolutionYou must start the IBM Tivoli Utilization sensor from the extracted scriptpackage on the target system.

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


IpDeviceSensor


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


IP interface sensorThe IP interface sensor discovers IP interfaces.


IpInterfaceSensor

Limitations

For IPv6 and IPv4 Router Details, the IP forwarding attribute is set to falseregardless of the setting on the discovered Windows system. Do not enable the IPinterface sensor. The function that the IP interface sensor provides is now providedby the appropriate computer system sensor. Enabling the IP interface sensor cancause performance issues.


The sensor creates the following model objects:v net.IpInterfacev net.IpV4Routerv net.IpV6Routerv sys.ComputerSystem

Ping sensorThe ping sensor discovers reachable IP addresses. It gathers information fromdevices and systems that support TCP/IP.


PingSensor

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the ping sensor uses.

com.collation.discover.agent.PingSensor.timeout=600000This value specifies the time interval in milliseconds before a timeoutoccurs during a discovery.

com.collation.pingagent.ports=xx,yy,...This property is not defined in the collation.properties file and must bemanually added if needed. Valid values are non-negative numbers thatrepresent ports for the ping sensor to use.

By default, the ping sensor uses port 22, and if it cannot make a connectionto port 22, it uses port 135. To override the default set of ports that theping sensor uses, add this property to the collation.properties file, andspecify the port numbers as a comma-separated list.

For example, to add the SNMP port 161 to the existing ports that the Pingsensor 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 withthe following value:


com.collation.pingagent.ports=161

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

Ping sensor discovery ends with an unable to establishloopback connection message

ProblemThe sensor fails when the scope of discovery is large, due to a timeouterror and the following message 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 connectionat sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:172)at java.security.AccessController.doPrivileged(AccessController.java:246)at sun.nio.ch.PipeImpl.<init>(PipeImpl.java:188)at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:45)at java.nio.channels.Pipe.open(Pipe.java:148)at sun.nio.ch.WindowsSelectorImpl.<init>(WindowsSelectorImpl.java:192)at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:53)at java.nio.channels.Selector.open(Selector.java:224)at com.collation.platform.session.Ping$Connector.<init>(Ping.java:303)at com.collation.platform.session.Ping.pingArray(Ping.java:656)at com.collation.platform.session.Ping.pingLoop(Ping.java:574)at com.collation.platform.session.Ping.ping(Ping.java:557)at com.ibm.cdb.discover.sensor.net.ping.PingSensor.do_ping(PingSensor.java:75)at com.ibm.cdb.discover.sensor.net.ping.PingSensor.discover(PingSensor.java:92)at com.collation.discover.engine.AgentRunner.run(AgentRunner.java:214)at com.collation.discover.engine.DiscoverEngine.processWorkItem(DiscoverEngine.java:1184)at com.collation.discover.engine.DiscoverEngine$DiscoverWorker.run(DiscoverEngine.java:867)Caused by: java.nio.channels.ClosedByInterruptExceptionat java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:216)at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:543)at java.nio.channels.SocketChannel.open(SocketChannel.java:161)at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:120)... 16 more<log end>

SolutionUse one of the following methods to resolve the problems:v Perform the discovery on a smaller scope.v In the collation.properties file, increase the timeout value for a longer

discover time for the following property:com.collation.discover.agent.PingSensor.timeout=600000

Port sensorThe port sensor discovers open ports on a host system.

You can change certain aspects of the port sensor using the sensor configurationfile. You must create a custom discovery profile to change the port sensorconfiguration. Before changing the configuration file, contact IBM SoftwareSupport.


PortSensor


Session sensorThe session sensor creates a session between the TADDM server and the targetcomputer system. Typically, the session is either a Secure Shell (SSH) session or aWindows Management Instrumentation (WMI) session.


SessionSensor

Configuring the access list

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

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


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 duringthe TADDM installation.

v Sudo tool for non-Windows operating systems.

For TADDM on AIX operating systems: For the TADDM user to use the nmaptool through sudo, you must install and configure sudo version 1.6.7p5. This isbecause TADDM has problems with the most recent sudo version, which isversion 1.6.9p15.

Security issues

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

Limitations

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


nmap -T Normal -O -sS -sU -oX - IPaddress

Application servers and services discovered using a credential-less (Level 1)discovery are reconciled with the application servers and services using a Level 2or Level 3 discovery, only if the binding TCP ports are the same. All applicationservers and services discovered using a Level 1 discovery remain following a Level2 or Level 3 discovery, but applications and services matching on the binding portsare merged.


The sensor creates the following model objects:v net.IpAddressv net.IpInterfacev net.L2Interfacev sys.aix.Aixv sys.aix.AixUnitaryComputerSystemv sys.ComputerSystemv sys.hpux.HpUxv sys.hpux.HpUxUnitaryComputerSystemv sys.i5OS.I5OperatingSystemv sys.linux.Linuxv sys.linux.LinuxUnitaryComputerSystemv sys.OperatingSystemv sys.sun.Solarisv sys.sun.SunSPARCUnitaryComputerSystemv sys.tru64.Tru64v sys.windows.WindowsComputerSystemv sys.windows.WindowsOperatingSystemv sys.zOS.ZOSv sys.zOS.ZSeriesComputerSystem

Configuring the sensorBefore running a discovery of the installed operating system and open ports, youmust configure the Stack Scan sensor.

Configuring NmapThe Stack Scan sensor uses Nmap to gather data about the targets forcredential-less discovery.

Installing Nmap

Before installing Nmap for any operating system, see the TADDM support site athttp://www.ibm.com/software/sysmgmt/products/support/IBMTivoliApplicationDependencyDiscoveryManager.html for recent news aboutyour specific operating system and Nmap versions.

Nmap is not installed during the TADDM installation. The Nmap tool is availableon TADDM DVD #2, and you must install it manually. Install Nmap on theTADDM server and all anchor servers. For more information, see the readme file inthe Nmap directory on the DVD.


http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliApplicationDependencyDiscoveryManager.html

http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliApplicationDependencyDiscoveryManager.html

Configuring root authority

For non-Windows platforms, give root authority for all commands to the TADDMuser ID that starts the TADDM server.

If you are using a TADDM anchor server, give root authority to the discoveryservice account on the anchor server.

As root user, add the following line in the /etc/sudoers configuration file, usingthe visudo command:TADDM_userid ALL=(ALL) NOPASSWD:ALL

wherev TADDM_userid is the user ID that starts the TADDM server, or the discovery

service account on an anchor.

If the sudoers file contains a Defaults requiretty line, comment it out or deletethe line.

When the Stack Scan sensor is running with Nmap, the TADDM server user IDcan be given root execution permission only for the Nmap command. Add thefollowing line in the /etc/sudoers configuration file:TADDM_userid ALL=(ALL) NOPASSWD:nmap_path

wherev TADDM_userid is the user ID that starts the TADDM server, or the discovery

service account on an anchor.v nmap_path is the full path to the location of the nmap command.

If the sudoers file contains a Defaults requiretty line, comment it out or deletethe line.

Configuring the Path environment variable

Nmap must be installed on your TADDM server and on all anchor servers. TheNmap command must be in the $PATH environment variable for the TADDM userID that starts the TADDM server. If you are using a TADDM anchor server, theNmap command must be in the $PATH environment variable for the discoveryservice account.

On Windows platforms, take the following steps to set the Path systemenvironment variable to include the directory where Nmap is installed:1. Click Start > Control Panel > System

2. Click the Advanced tab, and select Environment Variables.3. Edit the Path system variable and add the directory where Nmap is installed.4. Restart the computer.

This task makes Nmap available to services on the computer.

Verifying that Nmap is working

To verify that Nmap is working complete the following steps:1. Log in to the system using one of the following TADDM user IDs:

v The user ID that starts the TADDM server.


v The user ID that starts the discovery service account on the anchor server.2. Run the following command:

sudo nmap -T Normal -O -sS -oX - IPaddress/32

wherev IPaddress is a valid host system that is up and running on your network.The output produces an XML document that shows the ports and operatingsystems on that computer system.

Limitation

Because of a limitation on AIX, only four active Nmap commands can be run atthe same instance. To ensure that this limit of Nmap commands is not exceeded,complete the following steps:1. Create a discovery profile.2. In the new discovery profile, create a StackScanSensor configuration, and

enable the configuration.3. Set the values of the following properties to 1:

v nmapMaxOsScanTreadsv nmapMaxPingScanTreads

4. To save the configuration, click OK.5. To save the discovery profile, click Save. Use this discovery profile for

StackScan discoveries.6. If the number of computer systems in the scope being discovered exceeds 2048,

set the following property in the collation.properties file:com.collation.discover.dwcount=4

Configuring the discovery profileIf you want to create application servers based on the active TCP/IP portsdiscovered, update the discovery profile for the Stack Scan sensor.

To configure the sensor to create application servers, complete the following steps:1. Create a new discovery profile based on a TADDM Level 1 profile.2. Create a new sensor configuration in the new profile based on the Stack Scan

sensor configuration.3. In the new sensor configuration, set the enableNmapPortApplicationCreation

property to true.

You can further configure which application servers are to be created based on thediscovered ports using the PortAppScanSensor.properties file located in theosgi\plugins\com.ibm.cdb.discover.sensor.idd.stackscan_7.1.2\etc directory.Specific instructions for modifying the association between ports and applicationservers appear at the top of the PortAppScanSensor.properties file.

Configuration errors in the PortAppScanSensor.properties file are reported in thePortAppScanSensor.errors file, located in the osgi\plugins\com.ibm.cdb.discover.sensor.idd.stackscan_7.1.2\etc directory.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Stack Scan sensoruses.


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

com.collation.sudoCommand=sudoThis value specifies the sudo location.

com.collation.discover.agent.StackScanSensor.timeout=7200000This value specifies the time interval in milliseconds before a timeoutoccurs during a discovery.

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

The Stack Scan sensor completes successfully, but no ComputerSystems are stored

ProblemDoing a Level 1 discovery, the Stack Scan sensor finishes without errors,but it does not store any computer system information. In theservices/DiscoveryManager.log, you see the following message:2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])]WARN cdb.STDERR - Mar 26, 2008 11:05:26 AM invocation failed:sudo: sorry, you must have a tty to run sudoFrom the TADDM server command line you can successfully do ansu - <run as user>and thensudo "nmap -0 10.1.2.3

Solution

For non-windows platforms, give root authority for all commands to theTADDM user ID that starts the TADDM server. In addition, if you areusing a TADDM anchor server, give root authority to the discovery serviceaccount on the anchor server. See “Configuring Nmap” on page 171 fordetails.

The Stack Scan sensor does not discover Computer Systems ona Linux system

ProblemOn a Linux server, when performing a Level 1 discovery, the Stack Scansensor completes successfully, however, there are no Computer Systemsstored.

In the services/DiscoveryManager.log, the following message can be seen:2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])]WARN cdb.STDERR - Mar 26, 2008 11:05:26 AM invocation failed: sudo: sorry,you must have a tty to run sudo

You see this error even though the sudo command works successfully forthe run_as user from the command line.

SolutionComplete the following steps:1. Type the OS command visudo to edit the /etc/sudoers file2. Once the file opens, comment out the line Defaults requiretty.3. Save and close the file.


The network configuration on Linux for System z systems doesnot create packets that Nmap can read

Linux for System z supports both OSA and VSWICH network interfaces operatingin Layer 3 (Network Layer) or Layer 2 (Link Layer) mode. If operating in Layer 2mode, TCP packets contain a valid ethernet Link Layer header required by Nmap.However, systems using OSA or VSWITCH operating in Layer 3 mode requireadding the QETH_OPTIONS=’fake_ll=1’ to the hardware configuration file for theinterface. The following section describes how to modify the hardwareconfiguration file enabling Nmap to operate with Layer 3 network interfaces.

For more information about OSA and VSWITCH and their operating modes, seeChapter 7 “qeth device driver for OSA-Express (QDIO) and HiperSockets™” in theLinux on System z Device Drivers, Features, and Commands at: http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/lk31dd03.pdf.

ProblemThe network configuration on Linux for System z systems does not createpackets that Nmap can read.

The Stack Scan sensor uses Nmap to gather data about the targets forcredential-less discovery. If Nmap is not working properly, the Stack Scansensor does not store any computer systems.

Although the sensor runs without errors, the Linux for System z systemthat is running the Stack Scan sensor returns the following message:stored - 0 ComputerSystems in the database

If you type the nmap <hostname> command for any system other than thelocal host, the following message is displayed:Note: Host seems down. If it is really up,but blocking our ping probes, try -P0...

SolutionDepending on your operating system, perform the following actions:

On SUSE Linux for System z systemsThe network must run with the following option:QETH_OPTIONS=’fake_ll=1’

Add this option to the configuration file for the NIC. Dependingon the NIC that is used, the name of the file changes. Contact yoursystem administrator for the name of the configuration file thatyour system uses.

The configuration file must be in the /etc/sysconfig/hardwaredirectory. The file name might be hwcfg-qeth-bus-ccw-0.0.5000.

On RedHat Linux for System z systemsThe network must run with the following option:OPTIONS=’fake_ll=1’

Add this option to the configuration file for the NIC. Dependingon the NIC that is used, the name of the file changes. Contact yoursystem administrator for the name of the configuration file thatyour system uses.


http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/lk31dd03.pdf



The configuration file must be in the /etc/sysconfig/network-scripts directory. The file name might be ifcfg-eth0.

Verify that the alias in the /etc/modprobe.conf file includes thefollowing information:alias eth0 qeth

Computer system displays in the incorrect category

ProblemThe computer system displays under the OtherComputerSystem category.

SolutionCheck the OS type. If it is correct, check the confidence. If the confidence isbelow the confidence threshold value (the default is 40), then what you areseeing is expected.

You can change the confidence threshold to have the computer systemappear under the correct category. The threshold is configured 0 - 100. Thethreshold can be set using the sensor configuration attribute:confidenceThreshold.

Need enhanced Stack Scan sensor debugging

ProblemNeed to enable enhanced debugging of the Stack Scan sensor.

SolutionComplete the following steps:1. Check the local-anchor-<machine>.log file to see if Nmap was used by

the sensor.2. Enable further debugging by doing the following:

In the collation.properties file, set one of the following:v com.collation.log.level.StackScanSensor=TRACE

v com.collation.log.StackScanSensor=TRACE

v com.collation.log.level=TRACE

This method produces a verbose trace of what the sensor is doing, theresults, the configurations used, and more.

Stack Scan sensor fails with a message: sudo: sorry, you musthave a tty to run sudo

ProblemDuring a discovery, if the Discovery Management Console where theTADDM server was started is closed, the sensor fails. The message:sudo:sorry, you must have a tty to run sudo is displayed. If you startthe Discovery Management Console and leave it open the sensor works.

Solution

Comment out or delete the Defaults requiretty line from the/etc/sudoers configuration file on the TADDM server.

Stack Scan sensor is unable to run the sudo nmap command

ProblemThe Stack Scan sensor fails with the following error message: "Sorry, sudohas been configured to not allow root to run it." However, you cansuccessfully run sudo nmap at a command line.


SolutionThis problem occurs when the system is configured not to allow the rootuser to run the sudo command. To fix the problem, edit thecollation.properties file and set thecom.ibm.cdb.discover.sensor.idd.stackscan.alwaysUseLocalAnchor propertyto true. Then restart the TADDM server.

The Stack Scan sensor does not discover Computer Systems onan AIX system

ProblemOn an AIX server, when performing a Level 1 discovery, the Stack Scansensor completes successfully, however, there are no Computer Systemsstored.

In the services/DiscoveryManager.log, the following message can be seen:2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])]DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])] DEBUG stackscan.ExecCmd - standard err:/taddm/cmdb/dist/nmap/nmap-4.76/nmap[25]: 708778 Segmentation fault(coredump)

In the Nmap folder a core file is created during the discovery.

SolutionCreate a discovery profile or edit an existing profile for the Stack Scansensor. In the Configuration section of the Create Configuration window,click nmapExec. Then double-click the Value field in the row, and append-d to the value nmap. For example, the new value is nmap -d.


Chapter 5. Network sensors

Network sensors discover network devices.

Overview of SNMP sensorsTADDM provides SNMP sensors for discovering SNMP network devices.

Calling sequence for SNMP sensorsThe calling sequence for SNMP sensors is dependent on which sensors are enabledin the discovery profile and on what data is discovered.

In Level 1 discovery profiles, use the SNMP Light sensor with the Stack Scansensor to improve the accuracy of the discovery. In Level 2 or Level 3 discoveryprofiles, use the SNMP MIB2 sensor, which discovers additional data for buildingdetailed Level 2 topologies.

Figure 1 on page 180 illustrates the calling sequence for the SNMP Light sensorand the SNMP MIB2 sensor.

The ping sensor calls the port sensor.

If the SNMP Light sensor is enabled, the port sensor calls the SNMP Light sensor.If the port sensor discovers WMI or SSH ports and if the session sensor is enabled,the port sensor launches the session sensor. If the port sensor does not discoverWMI or SSH ports or if the session sensor cannot establish a connection to theremote host, the port sensor calls the SNMP MIB2 sensor.

Figure 2 on page 180 illustrates the calling sequence for SNMP sensors, startingafter the SNMP Light sensor or the SNMP MIB2 sensor is called.

Depending on the data that the SNMP Light sensor or the SNMP MIB2 sensordiscovers from the devices, the following sensors are called:v If a Cisco device is discovered, the Cisco port sensor and the Cisco VLAN sensor

are called.v If a Fibre Channel switch is discovered, the Fibre Channel switch sensor is

called.v If no Fibre Channel switch is discovered, the Entity MIB sensor and the Bridge

SNMP sensor are called. However, these sensors must be enabled in thediscovery profile.

v If the discovered device matches a custom MIB computer system template, theCustom MIB2 computer system sensor is called.


SNMP MIB walking and debugging SNMP sensorsYou can log SNMP get requests that are sent by the sensors.

To do so, add the following property to the collation.properties file:com.collation.Discover.jvmargs=-Xmx2048M-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider-Dcom.collation.platform.snmp.SnmpPackedPDU.trace=true

You can then compare entries in the log file output with direct SNMP queries yourun against the devices using snmpwalk. You can download SNMP query toolsthat support snmpwalk from http://www.net-snmp.org/download.html.

If SNMP V3 authentication is used with encryption, you must also downloadOpenSSL from http://www.slproweb.com/products/win32openssl.html.

The following example shows identical queries, with the first using V3authentication (although the keys have been removed) and the second usingcommunity string authentication:

PingSensor

PortSensor

SnmpLightSensor

SessionSensor

Connectionmade

SnmpMib2Sensor

WMI or SSHavailable

No

No Yes

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

SnmpMib2SensorSnmpLightSensor

Yes

CiscoVlanSensorCiscoPortSensorCustomMib2ComputerSystemSensor

Is CustomCS?

Is Ciscodevice?

Yes

BridgeSnmpSensorEntityMIBSensorFCSwitchSensor

Is FCswitch?

Yes No

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


http://www.net-snmp.org/download.html

http://www.slproweb.com/products/win32openssl.html

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "my authentication password"-x DES -X "my encryption key" 10.199.250.9 .1.3.6.1.2.1.4.20.1

snmpwalk -v 1 -c 5FFGkFaFNs 10.199.250.9 .1.3.6.1.2.1.4.20.1

Maintaining SNMP computer system templates andconfiguration files

You can use the Computer Systems view to maintain a list of templates that can beused to discover network devices.

You can partially define a device, link this definition to a template and then usethe template to discover more information about the device.

An OID is assigned to a device by the manufacturer and is unique to the makeand model of the device. Similar devices of the same model have the same OID.You can typically determine the type of device you have found by searching theWeb. This value can also be obtained for the device by querying the SNMPv2-MIBtables for values under the sysObjectID 1.3.6.1.2.1.1.2.

The SNMP templates and their configuration files are loaded dynamically duringeach discovery. It is not necessary to restart the TADDM server after modifying theSNMP templates and their configuration files. It is important to use the correctsyntax and enter the correct values when editing templates and configuration files.

If your devices are not correctly classified after a discovery, review theSnmpMib2Sensor log or the DiscoveryManager log file.

For 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 ApplicationDependency Discovery Manager information center.

The following results show different OIDs discovered through SNMP scans of fourFoundry devices. In scanning a test environment, the OIDs outlined in Table 9were discovered. You can perform an Internet search to determine the type ofdevices. Alternatively, you can ask your network team to identify the specificdevice types.

Table 9. Foundry OID mapping example

Foundry device OID Description

Foundry FESX448-PREM .1.3.6.1.4.1.1991.1.3.34.2.1.1.2 Router

Foundry FastIron SX .1.3.6.1.4.1.1991.1.3.36.6.2 Unknown (classified as aswitch for our testing)

Foundry BigIron RX .1.3.6.1.4.1.1991.1.3.40.1.2 Unknown (classified as aswitch for our testing)

Foundry NetIron MLX .1.3.6.1.4.1.1991.1.3.44.2.2 Unknown (classified as arouter for our testing)

You can create templates to classify discovered Foundry devices.

Foundry switch exampleThis example shows how to create the SNMP computer system template for aFoundry switch.

Chapter 5. Network sensors 181

Procedure1. In the Discovery Management Console, click Discovery > Computer Systems.2. In the Computer Systems view, click Add. The Computer System Details

window opens.3. In the Name field, type Foundry Switch.4. In the Action field, select Discover.5. Select Enabled.6. Optional: In the Icon field, click Browse to choose an icon for the device. This

icon is used only to distinguish the template in the Computer Systems view.(The icon is not used during or after discovery.)

7. Select MIB.8. In the Identifying Criteria field, select Any Criteria.9. For the first criterion, specify the following values:

Sys OID is .1.3.6.1.4.1.1991.1.3.34.2.1.1.1

Then click Add Criterion.10. For the second criterion, specify the following values:

Sys OID starts-with .1.3.6.1.4.1.1991.1.3.36

Then click Add Criterion.11. For the third criterion, specify the following values:


Then click Add Criterion.12. Click OK. The new template is added to the end of the list.13. To add an action class file for the template, create a file named Foundry

Switch.xml in the $COLLATION_HOME/etc/templates/action directory. Add thefollowing content to the file:<?xml version="1.0" encoding="UTF-8"?>

<resultsxmlns="urn:www-collation-com:1.0"xmlns:coll="urn:www-collation-com:1.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:www-collation-com:1.0urn:www-collation-com:1.0/results.xsd">

<UnitaryComputerSystem array="1" xsi:type="coll:com.collation.platform.model.topology.sys.UnitaryComputerSystem">

<type>Bridge</type><manufacturer>Foundry Networks</manufacturer>

</UnitaryComputerSystem></results>

This XML file specifies that all discovered SNMP computer system devicesmatching the Foundry Switch template use thecom.collation.platform.model.topology.sys.UnitaryComputerSystem modelclass, have the type attribute set to Bridge and the manufacturer attribute set toFoundry Networks.

Note: The name of the action class file (without the .xml extension) mustmatch the name of the SNMP computer system template.


What to do next

The new template can be used immediately (you do not need to restart theTADDM server).

Foundry router exampleThis example shows how to create the SNMP computer system template for aFoundry router.

Procedure1. In the Discovery Management Console, click Discovery > Computer Systems.2. In the Computer Systems view, click Add. The Computer System Details

window opens.3. In the Name field, type Foundry Router.4. In the Action field, select Discover.5. Select Enabled.6. Optional: In the Icon field, click Browse to choose an icon for the device. This

icon is used to distinguish the template in the Computer Systems view. (Theicon is not used during or after discovery.)

7. Select MIB.8. In the Identifying Criteria field, select Any Criteria.9. For the first criterion, specify the following values:

Sys OID is .1.3.6.1.4.1.1991.1.3.34.2.1.1.2

Then click Add Criterion.10. For the second criterion, specify the following values:


Then click Add Criterion.11. Click OK. The new template is added to the end of the list.12. To add an action class file for the template, create a file named Foundry

Router.xml in the $COLLATION_HOME/etc/templates/action directory. Add thefollowing content to the file:<?xml version="1.0" encoding="UTF-8"?>

<resultsxmlns="urn:www-collation-com:1.0"xmlns:coll="urn:www-collation-com:1.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:www-collation-com:1.0urn:www-collation-com:1.0/results.xsd">

<UnitaryComputerSystem array="1" xsi:type="coll:com.collation.platform.model.topology.sys.UnitaryComputerSystem">

<type>Router</type><manufacturer>Foundry Networks</manufacturer>

</UnitaryComputerSystem></results>

This XML file specifies that all discovered SNMP computer system devicesmatching the Foundry Router template use thecom.collation.platform.model.topology.sys.UnitaryComputerSystem modelclass, have the type attribute set to Router and the manufacturer attribute set toFoundry Networks.


Note: The name of the action class file (without the .xml extension) mustmatch the name of the SNMP computer system template.

What to do next

The new template can be used immediately (you do not need to restart theTADDM server).

Alteon port sensorThe Alteon port sensor discovers Alteon switch port information, including portsthat operate in auto negotiation mode and duplex mode.

The ports are stored in L2Interface with the auto negotiation (enabled or disabled)information. The duplex mode (half duplex or full duplex) is also stored.


AlteonPortSensor

Object identifiers (OIDs) that are used

The sensor uses the following OIDs:v curCfgTable: .1.3.6.1.4.1.1872.2.1.2.3.2.1v portInfoTable: .1.3.6.1.4.1.1872.2.1.9.1.1.1


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


To configure the access list, enter the following information:v For SNMP V1 and V2 discovery, enter the correct Community String into the

access list.You can do this using the Network Template (SNMP) Component Type in theAccess List window in the Discovery Management Console.

v For SNMP V3 discovery, enter the correct user name, password, andauthentication protocol into the access list, according to the SNMP V3 credentialmapping information in the following table:

Map from this: To this:

Authentication type (MD5, for example) Authentication Protocol

MD5 Secret Key Password and Confirm Password

Private Authentication Description or Key Private Password

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


Alteon SNMP sensorThe Alteon SNMP sensor discovers Alteon load balancer devices.

The sensor discovers the following items:v Real servers and real server groups. Real servers are partitioned into the

respective real server groups. Additional information, such as theLoadBalancingAlgorithm, is also discovered and stored with the real servergroup.

v Virtual ports, real ports, and virtual servers used to create and store virtualservices.


AlteonSnmpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v .1.3.6.1.4.1.1872.2.1.5.5.1.1v .1.3.6.1.4.1.1872.2.1.5.5.1.2v .1.3.6.1.4.1.1872.2.1.5.5.1.4v .1.3.6.1.4.1.1872.2.1.5.2.1.1v .1.3.6.1.4.1.1872.2.1.5.2.1.2v .1.3.6.1.4.1.1872.2.1.5.2.1.3v .1.3.6.1.4.1.1872.2.1.5.2.1.10v .1.3.6.1.4.1.1872.2.1.5.10.1.1v .1.3.6.1.4.1.1872.2.1.5.10.1.2v .1.3.6.1.4.1.1872.2.1.5.10.1.3v .1.3.6.1.4.1.1872.2.1.5.10.1.7v .1.3.6.1.4.1.1872.2.1.5.8.1.1v .1.3.6.1.4.1.1872.2.1.5.8.1.2v .1.3.6.1.4.1.1872.2.1.5.8.1.3v .1.3.6.1.4.1.1872.2.1.5.8.1.4v .1.3.6.1.4.1.1872.2.1.5.8.1.5v .1.3.6.1.4.1.1872.2.1.5.8.1.6


The sensor creates the following model objects:v net.vip.RealServerGroupv net.vip.Vipv net.vip.VipFunctionv net.vip.Virtualservicev sys.UnitaryComputerSystemv sys.Function net.vip.RealServer











Alteon VLAN sensorThe Alteon VLAN sensor discovers Alteon virtual LANs. This sensor uses theAlteon VLAN Membership MIB to discover VLAN contents.

The SnmpMib2Sensor invokes the AlteonVlanSensor when VLANs are configuredfor Alteon devices. AlteonVlanSensor then invokes BridgeSnmpSensor2 for eachVLAN discovered.

The sensor discovers the VLAN membership table, creates L2Interfaces, andattaches them to the VLAN bridge.


AlteonVlanSensor


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


The sensor creates the following model objects:v net.L2Interfacev net.Vlanv net.VlanInterfacev sys.UnitaryComputerSystem











BIG-IP port sensorThe BIG-IP port sensor discovers F5 BIG-IP port interfaces.

The SnmpMib2Sensor invokes the BigIPPortSensor. The BigIPPortSensor gathersports from the MIB, for example, the interface through which known ports can beaddressed. This allows L2 topology views to be built.


BigIPPortSensor


The sensor follows the standards documented in RFC 1212 to retrieve ports fromthe MIB. Specifically, OID .1.3.6.1.4.1.3375.1.1.5.2.1 is queried to get the interfacethrough which the port from the MIB can be discovered.


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



access list.


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







BIG-IP SNMP sensorThe BIG-IP SNMP sensor discovers F5 BIG-IP load balancers.

The SnmpMib2Sensor invokes the BigIPSnmpSensor if the latter one matches oneof the following OIDs:v .1.3.6.1.4.1.3375v .1.3.6.1.4.1.2021.250.255

The BigIPSnmpSensor collects information about virtual IPs and real server groups.


BigIPSnmpSensor

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.


The sensor follows the standards that are documented in RFC 1212 to get the RealServer Database (RSD) and the Virtual Server Database (VSD) table entries.

The sensor uses the following OIDs:

F5 BIG-IP version 4:

v Pool member table: 1.3.6.1.4.1.3375.1.1.8.2.1v Pool table: 1.3.6.1.4.1.3375.1.1.7.2.1v Virtual Server table: 1.3.6.1.4.1.3375.1.1.3.2.1



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


v Pool member table: 1.3.6.1.4.1.3375.2.2.5.3.2v Pool table: 1.3.6.1.4.1.3375.2.2.5.1.2v Virtual Server table: 1.3.6.1.4.1.3375.2.2.10.1.2v Virtual Server Rule table: 1.3.6.1.4.1.3375.2.2.10.8.2v Virtual Address table: 1.3.6.1.4.1.3375.2.2.10.10.2


The sensor creates the following model objects:v bigip.BigIPRealServerv bigip.BigIPRealServerGroupv bigip.BigIPVipv bigip.BigIPVipFunctionv bigip.BigIPVirtualServicev sys.UnitaryComputerSystem










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


The SnmpMib2Sensor invokes the BigIPVlanSensor. A VlanInterface model object iscreated for each VLAN in the VLAN map (for example, the interface throughwhich known VLANs can be addressed). This allows L2 topology views to bebuilt.


BigIPVlanSensor


The BigIPVlanSensor follows the standards documented in RFC 1212 to get theVLAN Interface. Specifically, OID .1.3.6.1.4.1.3375.1.1.10.2.1 is queried to get theVLAN interface through which the VLAN from the MIB can be discovered.

The BigIPVlanSensor runs the agent's discovery step and discovers Vlans andVlanInterfaces and throws an AgentException if the discovery fails.


The sensor creates the following model objects:v bigip.BigIPVlanv net.L2Interfacev net.VlanInterface










Bridge SNMP sensorThe Bridge SNMP sensor expands and updates the port data that is discovered bythe SNMP MIB2 sensor (which is the data that is shown in the Ports tab of theDetails pane).


The SNMP MIB2 sensor invokes the Bridge SNMP sensor. The Bridge SNMPsensor gathers the MAC address data of attached devices (specifically, the interfacenumber through which known MAC-addressed devices can be reached), which isneeded to build the Level 2 topology views.

The sensor follows the standards documented in RFC 1286 to retrieve some of theMAC Forwarding Database (fdb) table entries. The following OIDs are queried:v .1.3.6.1.2.1.17.4.3.1.1

v .1.3.6.1.2.1.17.4.3.1.2

OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses, asshown in the following example. These OIDs are then queried to determine theinterface through which the MAC device can be accessed.snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1

.1.3.6.1.2.1.17.4.3.1.1SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.42.208.0 = Hex-STRING: 00 12 F2 2A D0 00SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.50.0.0 = Hex-STRING: 00 12 F2 32 00 00SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.51.88.0 = Hex-STRING: 00 12 F2 33 58 00SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.218.128.177 = Hex-STRING: 00 12 F2 DA 80 B1SNMPv2-SMI::mib-2.17.4.3.1.1.0.208.4.45.228.10 = Hex-STRING: 00 D0 04 2D E4 0A

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1.1.3.6.1.2.1.17.4.3.1.1.0.18.242.42.208.0

SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.42.208.0 = Hex-STRING: 00 12 F2 2A D0 00

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1.1.3.6.1.2.1.17.4.3.1.2.0.18.242.42.208.0

SNMPv2-SMI::mib-2.17.4.3.1.2.0.18.242.42.208.0 = INTEGER: 282

The Bridge SNMP sensor also provides specific details about the Computer SystemL2 Interfaces that are attached to the switch. The SNMP MIB2 sensor providesgeneric information about the existence of the device interfaces, and the BridgeSNMP sensor provides detailed information about the MAC addresses that areaccessible through the device interfaces.

For example, Table 10 shows the names of MAC devices that have been discoveredby the Bridge SNMP sensor. TADDM can determine the names because thecomputer system that owns that MAC device has been discovered. If the name ofthe device is unknown, the MAC address is used.

Table 10. Level 2 bridge topology data

Name Computer System L2 Interfaces

ethernet 1/9 NC84CDRS1LDPC02

ethernet 1/10 00040DFDE53



ethernet 10/2 000CDBF90C19

The sensor also follows the standards that are documented in RFC 1286 to retrievesome of the port table information. The following OIDs are queried:v .1.3.6.1.2.1.17.1.4.1.1

v .1.3.6.1.2.1.17.1.4.1.2



BridgeSnmpSensor


The sensor follows the standards documented in RFC 1286 to get some of theMAC Forwarding Database (fdb) table entries. The following OIDs are queried:v .1.3.6.1.2.1.17.4.3.1.1v .1.3.6.1.2.1.17.4.3.1.2

OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses. TheseOIDs are then queried to retrieve the interface through which the MAC device canbe accessed.


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










Bridge SNMP 2 sensorThe Bridge SNMP 2 sensor expands and updates the port data that is discoveredby the SNMP MIB2 sensor for all virtual local area networks (VLANs).

The Bridge SNMP 2 sensor is invoked when VLANs are configured for the device.The Cisco VLAN sensor invokes the Bridge SNMP 2 sensor for each VLAN that isdiscovered. The data that is discovered is the same as for the Bridge SNMP sensor,but it is discovered for all VLANs.



BridgeSnmpSensor2


The sensor follows the standards documented in RFC 1286 to get some of theMAC Forwarding Database (fdb) table entries. The following OIDs are queried:v .1.3.6.1.2.1.17.4.3.1.1v .1.3.6.1.2.1.17.4.3.1.2.

OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses. TheseOIDs are then queried to retrieve the interface through which the MAC device canbe accessed.












Check Point sensorThe Check Point sensor discovers Check Point FireWall-1 running on non-Windowsplatforms, such as Solaris or Check Point IPSO.


CheckpointSensor


Prerequisites

You must have the following access:v SSH access that can run lsofv Read permission to the $CPMDIR/conf/objects.C directory on the system where

the Check Point FireWall-1 is runningv Execute permission for the $CPMDIR/bin/fw commandv Read permission to the $CPMDIR/conf/*.W files, which contain the editable

versions of the rule sets

The CPMDIR environment variable must be set for the TADDM user.


collation.properties file entries

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

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

Unable to retrieve information from the Check Point server hostmachine

ProblemThe Check Point sensor fails during discovery.

SolutionVerify that you have the following permissions:v Read permission to the $CPMDIR/conf/objects.C directory on the system

where the Check Point FireWall-1 is runningv Execute permission for the $CPMDIR/bin/fw commandv Read permission to the $CPMDIR/conf/*.W files, which contain the

editable versions of the rule sets

Check Point SNMP sensorThe Check Point SNMP sensor discovers SNMP information that is associated withCheck Point FireWall-1 firewalls.


CheckpointSnmpSensor

Prerequisites

The system object ID (sysObjectID) must return one of the following OIDs:v OID = .1.3.6.1.4.1.1919.v OID = .1.3.6.1.4.1.2620.


v OID.startsWith(.1.3.6.1.4.1.42.2.1.1.)

Limitations

The sensor collects the module, filter name, filter installation date, product name,major name, and minor name information.










Cisco Adaptive Security Appliance sensorThe Cisco Adaptive Security Appliance (ASA) sensor discovers ASA devices thatare used as IP firewall and network address translation appliances.

The Cisco ASA sensor gathers data about ASA devices. In addition, the sensordiscovers the following information:v All real servers and virtual services running. Real servers are grouped into the

real servers group.v The virtualIp, realIp, virtualPort, and realPort. The sensor also derives virtual

IPs using the virtualIp, realIp, virtualPort, and realPort. Virtual IPs are stored inthe Vip table.

Sensor name that is used in the GUI and logsv ASASensorv CiscoApplianceVersionSensor

Limitations

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



The sensor creates the following model objects:v cisco.CiscoPixComputerSystemv core.LogicalContentv net.L2Interfacev sys.OperatingSystemv vip.RealServerv vip.RealServerGroupv vip.Vipv vip.VipFunctionv vip.VirtualService



To configure the access list, complete the following steps:1. Select Cisco Device as the Component Type.2. Specify the access information (user name, password, and enable password)

that TADDM must use for authentication to the target ASA device.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Cisco ASA sensoruses.


com.collation.asa.pager.command=terminal pager 0Add this property and value if the user specified in the access list does nothave access to the configure terminal command.

The terminal pager 0 value instructs the pager command to force the ASAdevice to return responses in one batch.

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

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

Cisco Discovery Protocol sensorThe Cisco Discovery Protocol sensor uses the Cisco Discovery Protocol MIB todiscover Layer 2 segments on the network.


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


CdpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v Global Device Id : 1.3.6.1.4.1.9.9.23.1.3.4.0v Cache Device Id : .1.3.6.1.4.1.9.9.23.1.2.1.1.6v Cache Device Port : .1.3.6.1.4.1.9.9.23.1.2.1.1.7












v For TADDM to run a complete discovery, SNMP and Telnet must be enabled.You must configure Telnet access with a user name and password, and you mustenable the password.

Troubleshooting the sensorThis topic describes common problems that occur with the Cisco DiscoveryProtocol sensor and presents solutions for those problems.


After TADDM completes the discovery, the sensor name appearsin the GUI, but the Config files tab does not appear as expected

ProblemTelnet access is not configured correctly.

SolutionConfigure Telnet access with a user name and password, and make surethat the password is enabled.

Cisco IOS sensorThe Cisco Internetwork Operating System (Cisco IOS) sensor discovers Cisconetwork equipment using an SSH1, SSH2, or Telnet protocol.

The Cisco IOS sensor supports two-stage authentication:v Create the appropriate session client for SSH1, SSH2, or Telnet protocol.v Log on to the host.


CiscoIOSSensor


The sensor creates the following model objects:v agent.CiscoIOSAgentConfigurationv core.LogicalContentv sys.ComputerSystem



The following sensor attributes can be modified from the discovery profile:

useSshFirstThe default value for this attribute is false. The protocols are probed inthe order: Telnet protocol, SSH2, and SSH1. If the value is true: theprotocols are probed in the order: SSH2, SSH1, and Telnet protocol.

commandsThe default values for this attribute are show running-config;showstartup-config, if no value is entered. The output for each command issaved as a configuration file. To add additional commands, type thedefault commands show running-config;show startup-config and addadditional commands to the list. Separate each command with a semicolon.Alternatively, type the commands you want to run.


To configure the access list, complete the following steps:


1. Select CiscoDeviceAuth as the Component Type.2. Specify the access information (user name, password, and enable password)

that TADDM must use for authentication to the target computer system. Leavethe enable password blank if not required.

3. If your Cisco IOS sensor is using a Telnet protocol and does not prompt for auser name, type default in the user name field.

Cisco port sensorThe Cisco port sensor discovers Cisco switch port information.

The CiscoPortSensor discovers the interface index and duplex state for the port. Italso determines the auto negotiation status.


CiscoPortSensor


The sensor uses OID .1.3.6.1.4.1.9.9.87.1.4.1.1 for 2900 series Cisco devices.Otherwise OID .1.3.6.1.4.1.9.5.1.4.1.1 is used.














Cisco VLAN sensorThe Cisco VLAN sensor uses the Cisco VLAN Membership MIB to discover VLANcontents.

The SnmpMib2Sensor invokes CiscoVlanSensor when VLANs are configured forCisco devices. The CiscoVlanSensor then invokes BridgeSnmpSensor2 for eachVLAN discovered. The sensor discovers the VLAN membership table, createsL2Interfaces, and attaches them to the VLAN bridge.


CiscoVlanSensor


The sensor follows the standards documented in RFC 1286 to get the VLANinterface. The high level OIDs queried are:v OID .1.3.6.1.4.1.9.9.68.1.2.2.1.2 to get the VLAN membership tablev OID .1.3.6.1.4.1.9.9.46.1.2.1.1 to get the management domain tablev OID .1.3.6.1.4.1.9.9.46.1.3.1.1 to get the vtp VLAN tablev OID .1.3.6.1.4.1.9.9.46.1.6.1.1 to get the VLAN trunk port information.


The sensor creates the following model objects:v net.L2Interfacev net.Vlanv net.VlanInterfacev sys.UnitaryComputerSystem












CiscoWorks sensorThe CiscoWorks sensor collects data from CiscoWorks servers.

The sensor works by invoking the RME servlet.


CiscoWorksSensor, CiscoWorks405FileSensor, CiscoWorks405FileUDS,CiscoWorks405UDS, CiscoWorksFileSensor, CiscoWorksFileUDS, andCiscoWorksUDS

Model objects with associated attributesThe CiscoWorks sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects aboutconfiguration items from CiscoWorks servers.


net.IpAdress

v DotNotation

net.IpInterface

v IpAddressv L2Interface

net.L2Interface

v Descriptionv Encapsulationv HwAddressv Name

net.Router

v Forwardingv Name

sys.OperatingSystem

v Descriptionv Namev OSNamev OSVersion

sys.UnitaryComputerSystem

v Functionsv Manufacturerv Modelv Namev OSRunningv SerialNumber


v Type


To configure the access list, complete the following steps:1. Use CiscoWorks as the Component Type.2. Specify the following required information:


Entity MIB sensorThe Entity MIB sensor can discover only known devices. It follows the standardsthat are documented in RFC 2737 to retrieve some of the physical configurationinformation for the device.

The Entity MIB sensor gathers the data that is shown in the PhysicalPackage tab ofthe Details pane. This data is used to store information about physical parts of thedevice such as slot, fan, physical frame, sensors, physical connectors, chassis, rack,and power supply.

The sensor queries the following OIDs:.1.3.6.1.2.1.47.1.1.1.1.2, .1.3.6.1.2.1.47.1.1.1.1.3, .1.3.6.1.2.1.47.1.1.1.1.4,.1.3.6.1.2.1.47.1.1.1.1.5, .1.3.6.1.2.1.47.1.1.1.1.6, .1.3.6.1.2.1.47.1.1.1.1.7,.1.3.6.1.2.1.47.1.1.1.1.8, .1.3.6.1.2.1.47.1.1.1.1.9, .1.3.6.1.2.1.47.1.1.1.1.10,.1.3.6.1.2.1.47.1.1.1.1.11, .1.3.6.1.2.1.47.1.1.1.1.12, .1.3.6.1.2.1.47.1.1.1.1.13.

The sensor also gathers .1.3.6.1.2.1.55.1.1.0., which contains IPv6 informationaccording to RFC 2466. OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs forknown MAC addresses. These OIDs are then queried to determine the interfacethrough which the MAC device can be accessed.

If the SNMP MIB2 sensor also runs, additional information is gathered and shownin the Router Details, Bridge Details, IP, and Ports tabs.


EntityMIBSensor


The sensor uses the following OIDs:v .1.3.6.1.2.1.47.1.1.1.1.2v .1.3.6.1.2.1.47.1.1.1.1.3v .1.3.6.1.2.1.47.1.1.1.1.4v .1.3.6.1.2.1.47.1.1.1.1.5v .1.3.6.1.2.1.47.1.1.1.1.6v .1.3.6.1.2.1.47.1.1.1.1.7v .1.3.6.1.2.1.47.1.1.1.1.8v .1.3.6.1.2.1.47.1.1.1.1.9


v .1.3.6.1.2.1.47.1.1.1.1.10v .1.3.6.1.2.1.47.1.1.1.1.11v .1.3.6.1.2.1.47.1.1.1.1.12v .1.3.6.1.2.1.47.1.1.1.1.13

The sensor queries OID .1.3.6.1.2.1.55.1.1.0. which contains the IPV6 informationper RFC 2466. The sensor also queries OID .3.6.1.2.1.17.4.3.1.1. which returns a listcontaining OIDs for known MAC addresses. These OIDs are then queried to getthe interface through which the MAC device can be accessed.


The sensor creates the following model objects:v phys.physconn.Slotv physconn.PhysicalConnectorv physpkg.Chassisv physpkg.Fanv physpkg.PhysicalFramev physpkg.PhysicalPackagev physpkg.otherPhysicalPackagev physpkg.PowerSupplyv physpkg.Sensorv sys.ComputerSystem










Extreme VLAN sensorThe Extreme VLAN sensor extracts VLAN information from Extreme Networksswitches.


The SnmpMib2Sensor invokes the ExtremeVlanSensor when VLANs are configuredfor the device.


ExtremeVlanSensor


The sensor uses the following OIDs:v OID .1.3.6.1.4.1.1916.1.2.1.2.1 is used to query the extremeVlanInterface

Information.v OID .1.3.6.1.4.1.1916.1.2.3.1.1 is used to query the Encapsulation (Trunk) Interface

information.v OID .1.3.6.1.2.1.31.1.2.1 is used to query the Interface Stack information.












IBM BladeCenter SNMP sensorThe IBM BladeCenter® SNMP sensor discovers and collects configurationinformation about IBM BladeCenter chassis.

The sensor uses SNMP (Simple Network Management Protocol) to discover andquery BladeCenter infrastructure components. The Management Module (MM) andthe Advanced Management Module (AMM) are the central points of managementfor the IBM BladeCenter chassis.



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 tothe first BladeCenter discovery.

v The sensor might not obtain sufficient Vital Product Data (VPD) againstRedundant Management Modules to create certain model objects. Instances ofthe ComputerSystem and BladeCenterManagementModule classes representingRedundant Management Modules, for example, might not be created. In thiscase, instances of the Board class represent the module.

v After discovering one or more BladeCenters using the BladeCenter sensor, thecomponents BladeCenter and BladeCenter Management Module are not presentin the list of component types available for use with custom queries. Thereforeyou cannot run a custom query for these types of components. This issue appliesonly to the TADDM Data Management Portal and not to the DiscoveryManagement Console.

v The BladeCenter does not have L2 interfaces but has Management Moduleswhich have L2 interfaces. To view the L2 interfaces of the Management Modulescontained in the BladeCenter, complete the following steps:1. In the Details pane, click the Chassis tab to open the Chassis notebook.2. Click the MMs tab to open the Management Module notebook.3. In the Computer System column, click BladeCenter Management Module.4. Click the IP tab to view the L2 interface details.


The sensor creates the following model objects:v core.LogicalContentv enums.AlertLevelEnumv enums.PhysTypeEnumv enums.SlotStateEnumv IpAddress netv L2Interfacev net.BindAddressv net.Fqdn netv phys.physconn.PhysicalConnectorv phys.physconn.Slotv phys.physpkg.Boardv phys.physpkg.Chassisv phys.physpkg.Fan


v phys.physpkg.PhysicalFramev phys.physpkg.PowerSupplyv sys.blade.Alertv sys.blade.BladeCenterManagementModulev sys.blade.LoginProfilev sys.ComputerSystemv sysControlSoftwarev sys.DNSServicev sys.LDAPServicev sys.ServiceAccessPointv sys.SMTPService



You can configure the BladeCenterSnmpSensor using the Discovery ManagementConsole by setting the following attributes:

snmpPortThe port number used for SNMP communication. The default value is 161.

snmpTimeoutThe timeout used for a single SNMP query. The default value is 20000.

locale The locale used for SNMP queries.

characterEncodingThe character encoding used for SNMP queries.

scanL2InterfacesGet L2 interfaces for the chassis, when enabled.

For more information, see the topic “Creating discovery profiles” in the “Using ”topics in the IBM Tivoli Application Dependency Discovery Manager informationcenter.

When the BladeCenterSnmpSensor is enabled, you must also enable theSnmpLightSensor or SnmpMIB2Sensor for the BladeCenterSnmpSensor to functioncorrectly.











Troubleshooting the sensorThis topic describes common problems that occur with the IBM BladeCenter SNMPsensor and presents solutions for those problems.

An SNMP time out error occurs

ProblemThe sensor generates an SNMP time out error during discovery.

SolutionIncrease the snmpTimeout parameter for the BladeCenterSnmpSensor usingthe Discovery Management Console.

LAN Manager SNMP sensorThe LAN Manager SNMP sensor discovers LAN Manager and retrievesinformation contained in LAN Manager SNMP MIBs.


LanManagerSnmpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v .1.3.6.1.4.1.77.1.1.1.0v .1.3.6.1.4.1.77.1.1.2.0v .1.3.6.1.4.1.77.1.2.3.1.1v .1.3.6.1.4.1.77.1.2.3.1.2v .1.3.6.1.4.1.77.1.2.3.1.3v .1.3.6.1.4.1.77.1.2.3.1.4v .1.3.6.1.4.1.77.1.2.3.1.5


The sensor creates the following model objects:v sys.windows.WindowsComputerSystemv sys.windows.WindowsOperatingSystemv sys.windows.WindowsService











NetFlow sensorThe NetFlow sensor discovers network traffic information that is collected by theTivoli Netcool® Performance Flow Analyzer server. Tivoli Netcool PerformanceFlow Analyzer is a flow-based, network profiling system that analyzes andaggregates NetFlow data. It compiles the network flow data into reports andmakes the reports available to the NetFlow sensor.

Using Cisco NetFlow, network flow information is collected from routers andswitches and is passed, in the form of UDP packets, to a Tivoli NetcoolPerformance Flow Analyzer server.

See the TADDM Installation Guide for information about installing the TivoliNetcool Performance Flow Analyzer server.


NetFlowSensor

Limitations

A limited amount of Computer System information is discovered by using theNetFlow sensor. After a discovery, many of the fields in the Details tab of theComputer System remain empty.

The discovery scope and port information, defined in the scopeFilter andincludePorts properties, override any scope or port settings defined for individualdiscoveries.

If you perform a discovery of more than one subset simultaneously, an instance ofthe NetFlow sensor starts for each subset. One instance of the NetFlow sensorcollects computer system and network connection information from all the subnetsdefined by the scopeFilter property. All other instances of the NetFlow sensorreturn a null value.



The sensor creates the following model objects:v sys.ComputerSystemv net.IpInterfacev net.IpAddressv net.LogicalConnectionv net.NetworkConnection



To collect NetFlow data, the NetFlow sensor requires the Tivoli NetcoolPerformance Flow Analyzer server to be running. As part of the TADDM serverinstallation process, you can install the Tivoli Netcool Performance Flow Analyzerserver. For more information, see the “Installing” topics in the IBM TivoliApplication 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:

collectorDataDirectoryThe full path of the reports directory. The default location for thisdirectory is /var/lib/aurora/sites/taddm/reports.

collectorIPThe full host name or IP address of the Tivoli Netcool PerformanceFlow Analyzer server.

includePortsThe list of ports monitored. Information is collected by the NetFlowsensor for only the ports specified. The default value is80,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

processAppToAppDataThe default value for this attribute is true. The sensor processes theTivoli Netcool Performance Flow Analyzer a2a (port to port) files forcomputer system to computer system connections. Change this attributeto false to prevent this processing.

ProcessComputerSystemToAppDataThe default value for this attribute is true. The sensor processes theTivoli Netcool Performance Flow Analyzer cfa files for system tosystem information. Change this attribute to false to prevent thisprocessing.


ProcessIPv4DataThe default value for this attribute is true. Change this attribute tofalse to filter out the IPv4 data.

ProcessIPv6DataThe default value for this attribute is true. Change this attribute tofalse to filter out the IPv6 data.

restrictiveIPv4DataThe default value for this attribute is true. The sensor requires bothcomputer systems to be in the scope of discovery for the relationship tobe created for the IPv4 data. Change this attribute to false to requireonly one end point to be present.

restrictiveIPv6DataThe default value for this attribute is true. The sensor requires bothcomputer systems to be in the scope of discovery for the relationship tobe created for the IPv6 data. Change this attribute to false to requireonly one end point to be present.

scopeFilterThe scope of a discovery using the NetFlow sensor. If a scope filter isset, 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 networkconnections. The connections discovered are through Cisco NetFloweither to or from the computer systems in the scope filter for the sensor.Many of these connections are to or from other computer systems thatare outside of the scope filter for the sensor and that might or mightnot have been previously discovered.

4. Click OK.

The NetFlow sensor can retrieve NetFlow reports from the remote Tivoli NetcoolPerformance Flow Analyzer server. Depending on the network traffic, it can takeapproximately 24 hours for the remote Tivoli Netcool Performance Flow Analyzerserver 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 FlowAnalyzer server on the TADDM server. For this method, enter the location of themounted drive as the value of the collectorDataDirectory attribute, and leave thevalue of the collectorIP attribute empty.

v Configure the TADDM access list, and enter the IP address of the remote serveras the value of the collectorIP attribute.


If Tivoli Netcool Performance Flow Analyzer is not installed on the TADDM server,NetFlowSensor uses the ComputerSystem access entry to access the Tivoli NetcoolPerformance Flow Analyzer server.


NetScreen SNMP sensorThe NetScreen SNMP sensor discovers the NAT configuration from JuniperNetworks NetScreen devices and retrieves service values such as ServiceIndex,serviceName, and ServiceTransProto from NetScreen and looks up thevirtualservice.

The NetScreenSNMPSensor uses the Netscreen SNMP MIBs.


NetscreenSnmpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v .1.3.6.1.4.1.3224.11.1.1.1v .1.3.6.1.4.1.3224.11.1.1.2v .1.3.6.1.4.1.3224.11.1.1.3v .1.3.6.1.4.1.3224.11.1.1.4v .1.3.6.1.4.1.3224.11.1.1.5v .1.3.6.1.4.1.3224.11.1.1.6v .1.3.6.1.4.1.3224.13.1.1.1v .1.3.6.1.4.1.3224.13.1.1.2v .1.3.6.1.4.1.3224.13.1.1.4v .1.3.6.1.4.1.3224.13.1.1.5v .1.3.6.1.4.1.3224.13.1.1.6v .1.3.6.1.4.1.3224.13.1.1.7v .1.3.6.1.4.1.3224.13.1.1.8v .1.3.6.1.4.1.3224.11.3.1.1.1v .1.3.6.1.4.1.3224.11.3.1.1.2v .1.3.6.1.4.1.3224.11.3.1.1.3v .1.3.6.1.4.1.3224.11.3.1.1.4v .1.3.6.1.4.1.3224.11.3.1.1.5v .1.3.6.1.4.1.3224.11.3.1.1.6v .1.3.6.1.4.1.3224.11.3.2.1.1v .1.3.6.1.4.1.3224.11.3.2.1.2v .1.3.6.1.4.1.3224.11.3.2.1.3v .1.3.6.1.4.1.3224.11.3.2.1.5v .1.3.6.1.4.1.3224.11.3.2.1.6


The sensor creates the following model objects:v net.vip.RealServerv net.vip.RealServerGroupv net.vip.Vipv net.vip.VipFunctionv net.vip.VirtualService


v sys.ComputerSystem










Nokia SNMP sensorThe Nokia SNMP sensor discovers information contained in Nokia SNMP MIBs.

The NokiaSNMPSensor discovers Access Control List (ACL) configurations (ACLrules) and mapped interfaces for Nokia SNMP devices based on the FQDN,signature, and Object_ID.


NokiaSnmpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v .1.3.6.1.4.1.94.1.16.4.1.1.1.1v .1.3.6.1.4.1.94.1.16.4.1.1.1.2v .1.3.6.1.4.1.94.1.16.4.1.1.1.3v .1.3.6.1.4.1.94.1.16.4.1.1.1.4v .1.3.6.1.4.1.94.1.16.4.1.1.1.5v .1.3.6.1.4.1.94.1.16.4.2.1.1.1v .1.3.6.1.4.1.94.1.16.4.2.1.1.2v .1.3.6.1.4.1.94.1.16.4.2.1.1.3v .1.3.6.1.4.1.94.1.16.4.2.1.1.4v .1.3.6.1.4.1.94.1.16.4.2.1.1.5v .1.3.6.1.4.1.94.1.16.4.2.1.1.6v .1.3.6.1.4.1.94.1.16.4.2.1.1.7


v .1.3.6.1.4.1.94.1.16.4.2.1.1.8v .1.3.6.1.4.1.94.1.16.4.2.1.1.9v .1.3.6.1.4.1.94.1.16.4.2.1.1.10v .1.3.6.1.4.1.94.1.16.4.2.1.1.11v .1.3.6.1.4.1.94.1.16.4.2.1.1.12v .1.3.6.1.4.1.94.1.16.4.2.1.1.13v .1.3.6.1.4.1.94.1.16.4.2.1.1.14v .1.3.6.1.4.1.94.1.16.4.2.1.1.15v .1.3.6.1.4.1.94.1.16.4.2.1.1.16


The sensor creates the following model objects:v net.acl.Aclv net.acl.AclFunctionv net.acl.Rulev net.L2Interfacev sys.ComputerSystem










PIX sensorThe PIX sensor discovers Cisco PIX devices that are used as IP firewall andnetwork address translation appliances.

The PIX sensor gathers data about the CiscoPIX operating system running on PIXdevices. In addition the sensor does the following:v Discovers all real servers and virtual services running. Real servers are grouped

into the real servers group.


v Discovers the virtualIp, realIp, virtualPort, and realPort, and derives virtual IPsusing them. Virtual IPs are stored in the Vip table.

Sensor name that is used in the GUI and logsv CiscoApplianceVersionSensorv PixSensor

Prerequisite

For configurations that have multiple context configurations, specify in thediscovery scope the IP address of the “admin context.”

Limitations

When topologies are displayed, the following limitations apply:v For context configurations, the virtual and admin contexts are represented by the

same icon.v In the physical infrastructure topology view, the connection between the “admin

context” and the “virtual context” is not displayed. This connection is displayedin the contextual topology view.


The sensor creates the following model objects:v cisco.CiscoPixComputerSystemv core.LogicalContentv net.L2Interfacev sys.OperatingSystemv vip.RealServerv vip.RealServerGroupv vip.Vipv vip.VipFunctionv vip.VirtualService


To configure the access list, complete the following steps:1. Select Cisco Device as the Component Type.2. Specify the access information (user name, password, and enable password)

that TADDM must use for authentication to the target PIX device.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the PIX sensor uses.

com.collation.pix.pager.commandThis value specifies to use the pager command to force the PIX to returnthe entire response at once, rather than one screen at a time. Add thisentry, if it is not possible to run the configure terminal command.


SNMP Light sensorThe SNMP Light sensor supports Level 1 discovery of SNMP network devices.


The SNMP Light sensor gathers the data that is shown in the following tabs of theDetails pane:v Generalv SNMP Info

The SNMP Light sensor and the SNMP MIB2 sensor gather generic informationfrom the following object identifiers (OIDs):snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9

.1.3.6.1.2.1.1.1.0SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System SoftwareIOS (tm) s72033_rp Software (s72033_rp-JK9SV-M), Version 12.2(17d)SXB11,

RELEASE SOFTWARE (fc1)Technical Support: http://www.cisco.com/techsupportCopyright (c) 1986-2005 by cisco Systems, Inc.Compiled T

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "Y1UN9;4b/1tz9l#"10.199.250.9 .1.3.6.1.2.1.1.2.0

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.400


SNMPv2-MIB::sysContact.0 = STRING: Network Support - CH

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9.1.3.6.1.2.1.1.5.0

SNMPv2-MIB::sysName.0 = STRING: NC89ZNC01TSL302

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A “" -x DES -X "" 10.199.250.9.1.3.6.1.2.1.1.6.0

SNMPv2-MIB::sysLocation.0 = STRING: NC89ACB01


SnmpLightSensor


The sensor creates the following model objects:v sys.UnitaryComputerSystemv sys.OperatingSystemv sys.SnmpSystemGroup


To configure the access list, enter the following information:


v For SNMP V1 and V2 discovery, enter the correct Community String into theaccess list.You can do this using the Network Template (SNMP) Component Type in theAccess List window in the Discovery Management Console.







SNMP MIB2 sensorThe SNMP MIB2 sensor supports Level 2 discovery of SNMP network devices.


The SNMP MIB2 sensor discovers basic SNMP information about the device andother information such as router details, bridge details, IP data (both IPv4 andIPv6), and port data. The SNMP MIB2 sensor calls the Entity MIB sensor and theBridge SNMP sensor if they are enabled in the discovery profile.

Other sensors are called as the SNMP MIB2 sensor detects the devices thatTADDM supports (for example, the Cisco port sensor and the Cisco VLAN sensorare called if a Cisco device is detected).

The SNMP MIB2 sensor gathers the data that is shown in the following tabs of theDetails pane:v Generalv SNMP Infov IPv6 Router Detailsv IPv4 Router Detailsv IPv Interfaces

The SNMP Light sensor and the SNMP MIB2 sensor gather generic informationfrom the following object identifiers (OIDs):snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9

.1.3.6.1.2.1.1.1.0SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System SoftwareIOS (tm) s72033_rp Software (s72033_rp-JK9SV-M), Version 12.2(17d)SXB11,

RELEASE SOFTWARE (fc1)Technical Support: http://www.cisco.com/techsupportCopyright (c) 1986-2005 by cisco Systems, Inc.Compiled T



SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.400


SNMPv2-MIB::sysContact.0 = STRING: Network Support - CH

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9.1.3.6.1.2.1.1.5.0

SNMPv2-MIB::sysName.0 = STRING: NC89ZNC01TSL302

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A “" -x DES -X "" 10.199.250.9.1.3.6.1.2.1.1.6.0

SNMPv2-MIB::sysLocation.0 = STRING: NC89ACB01

The SNMP MIB2 sensor discovers IPv4 and IPv6 information. Using the IP-MIBand IP-FORWARD-MIB modules (updated in RFC 4293 and RFC 4292), the sensorcollects IP interface, forwarding, and routing information. The following OIDs arequeried:1.3.6.1.2.1.4.34 IP-MIB (ipAddressTable)1.3.6.1.2.1.4.32 IP-MIB (ipAddressPrefixTable)1.3.6.1.2.1.4.25 IP-MIB (ipv6IpForwarding)1.3.6.1.2.1.4.1 IP-MIB (ipForwarding)1.3.6.1.2.1.4.24.7 IP-FORWARD-MIB (inetCidrRouteTable)

ipAddressTableThis table lists the IPv4 and IPv6 addresses.

ipAddressPrefixTableThis table lists the prefix information for all addresses.

ipv6IpForwardingThis flag indicates whether the target device is acting as a router toforward IPv6 packets.

ipForwardingThis flag indicates whether the target device is acting as a router toforward IPv4 packets.

inetCidrRouteTableThis IP routing table lists the routes for both IPv4 and IPv6 interfaces.

If the target device supports the necessary versions of the IP-MIB andIP-FORWARD-MIB modules, the SNMP MIB2 sensor collects all the requiredinformation, and discovery completes. If the target device does not support thenecessary versions of these modules, the older versions (RFC 2011 and RFC 1213),which gather only IPv4 information, are used, and the following OIDs are queried:1.3.6.1.2.1.4.20 IP-MIB (ipAddrTable)1.3.6.1.2.1.4.1 IP-MIB (ipForwarding)1.3.6.1.2.1.4.21 RFC1213-MIB (ipRouteTable)

In addition, if the target device is a Cisco device, the CISCO-IETF-IP-MIB andCISCO-IETF-IP-FORWARDING-MIB modules are used to gather just the IPv6information, and the following OIDs are queried:1.3.6.1.4.1.9.10.86.1.1.2 CISCO-IETF-IP-MIB (cIpAddressTable)1.3.6.1.4.1.9.10.86.1.1.1 CISCO-IETF-IP-MIB (cIpAddressPfxTable)1.3.6.1.4.1.9.10.86.1.2.1 CISCO-IETF-IP-MIB (cIpv6Forwarding)1.3.5.1.4.9.10.85.7 CISCO-IETF-IP-FORWARD-MIB (cInetCidrRouteTable)



SnmpMib2Sensor

Limitations

TADDM currently supports a limited number of network devices. In addition,TADDM L2 switches are switches and L3 switches are routers. So, L3 switches aredisplayed as a Router in the Physical Infrastructure tree and in the Topology.

All computer system sensors and the SNMP MIB2 sensor ignore network interfacesthat are configured to be down. TADDM does not populate the net.IpNetworkattribute on the following types of IP interfaces:v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1v link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1v multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1v unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0

Therefore, IP networks are not populated in the TADDM user interface.


The sensor creates the following model objects:v net.Bridgev net.IpInterfacev net.IpRoutev net.IpV4Addressv net.IpV6Addressv net.IpV4Routerv net.IpV6Routerv net.L2Interfacev sys.UnitaryComputerSystemv sys.OperatingSystemv sys.SnmpSystemGroup












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

The sensor incorrectly identifies L3 switches as routers

ProblemFor SNMP devices that TADDM does not already know about, TADDMoccasionally misidentifies L3 switches as routers.

SolutionUse the SNMP templates to provide TADDM with hints to correctlyidentify the switches and routers. See the “Using” topics in the IBM TivoliApplication Dependency Discovery Manager information center forinformation about how to use SNMP templates to assist TADDM withcorrect switch, router categorization.

The sensor fails doing an OS discovery

ProblemThe sensor fails doing an OS discovery.

SolutionVerify the credentials provided in the access list and check to ensure thatSNMP is running on the TADDM client.


Chapter 6. Operating system sensors

Operating system sensors discover the operating systems that are running in theenvironment.

HP NonStop computer system sensorThe HP NonStop computer system sensor discovers the computer system that runsthe HP NonStop OSS operating system. The sensor works only in Asynchronousdiscovery mode.


HpNonStopComputerSystemSensor

Prerequisites

A discovery user needs to have access to both OSS and Guardian environment. AnASD script is executed from OSS environment.

You can create 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 GenericServer Sensor that starts Level 3 sensors is not supported on the HP NonStopplatform.


The sensor creates the following model objects:v core.LogicalContentv sys.hpnonstop.HpNonStopv sys.hpnonstop.HpNonStopComputerSystem

Asynchronous discovery supportThe HP computer system sensor supports asynchronous discovery.






Troubleshooting the sensorProblems with the sensor might include unsuccessful discovery or incorrectlydefined properties. However, you can recover from these problems.

General problems

Verify that the following sensors are enabled in the profile:v ASDPingSensorv ASDSensorv GenericComputerSystemSensorv HpNonStopComputerSystemSensor

Verify that the ASD packages are available for a discovery in a directory definedby property com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory.

HP-UX computer system sensorThe HP-UX computer system sensor discovers a computer system that is runningthe HP-UX operating system. If a system is running HP-UX on an Itaniumplatform with virtualization support (HP Integrity Virtual Machines), the sensordiscovers elements that are managed by the server.



Prerequisites

For a VM Host system on an Itanium platform, the TADDM service account musthave Execute permissions on the hpvmstatus and hpvminfo binary files.

For a guest system on an Itanium platform, the TADDM service account must haveExecute permissions on the hpvminfo binary files.

The TADDM service account must have Execute permissions on the machinfobinary files.

Limitations



Discovery of IPv6 address of a guest system through a VM Host is not availablefor HP-UX on an Itanium platform. Discovery of IPv6 address of a VM Hostthrough a guest system is not available for HP-UX on an Itanium platform.


Guest systems that are running non-HP-UX operating systems are not createdduring discovery of the VM host systems.

Discovery of IPv6 interfaces and IPv6 routing and forwardinginformation

The sensor discovers IPv6 interfaces and IPv6 routing and forwarding informationabout target systems that are configured to support IPv6. TADDM runs discoveriesagainst only IPv4 addresses. TADDM does not start a sensor against IPv6addresses. For DNS lookups, TADDM uses either the IPv4 or the IPv6 addresses.TADDM does not populate the net.IpNetwork attribute on an IPv6 interface if theprefix length value is unspecified or equals zero.

The discovered IPv6 addresses are displayed in the TADDM user interfacesimilarly to IPv4 addresses and are accessible using the TADDM API. Because IPv6addresses use a prefix length value instead of an IPv4 netmask, only one of thesevalues is populated for an IP address. The value depends on the address type.


The sensor creates the following model objects:v core.LogicalContentv sys.hpux.HpUxv sys.HpUxUnitaryComputerSystemv sys.SoftwareComponent



The HP-UX computer system sensor can be run using the ComputerSystem accesscredentials. To configure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM must

use for either SSH key-based authentication or SSH login-based authenticationto the target computer system.

Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process can require privilegeescalation. Typically, this escalation is done using the sudo command.




Chapter 6. Operating system sensors 223

com.collation.platform.os.command.machinfoThis property specifies the path to the machinfo command. If this propertyis not set, the default value of /usr/contrib/bin/machinfo is used.

com.collation.discover.agent.command.kcmoduleThis property specifies the path to the kcmodule command.

com.collation.platform.os.HpUxItanium.ModelUsed as a starting point for HpUx on Itanium. The default value is ia64.Change this property when the model command on HP-UX Itaniumsystems does not contain ia64 in the output.

com.collation.discover.agent.command.hpvminfoThis property specifies the path to the hpvminfo command. If this propertyis not set, the default value of /opt/hpvm/bin/hpvminfo is used.

com.collation.discover.agent.command.hpvmstatusThis property specified the path to the hpvmstatus command. If thisproperty is not set, the default value of /opt/hpvm/bin/hpvmstatus is used.

com.collation.platform.os.command.crontabEntriesCommand.HP-UX=crontab -lThis property is used to discover crontab entries. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesCommand.HP-UX.1.2.3.4=crontab -l

com.collation.platform.os.command.crontabEntriesUsers.HP-UX=rootThis property is used to discover crontab entries for a specified user, use acomma-separated list to specify more than one user. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesUsers.HP-UX.1.2.3.4=root,build

Troubleshooting the sensorThis topic describes common problems that occur with the HP-UX computersystem sensor and presents solutions for those problems.

General problems

Verify that the attributes, such as Architecture, processor type, processor speed,Memory size, or Serial number, are not populated.

Verify that the output of the model command contains ia64, and if it does not,verify that the target is HP-UX 11.23 on Itanium. Change thecom.collation.platform.os.HpUxItanium.Model property to include the uniqueidentifier from the model command output.

The Serial number attribute is not populated on Itanium by default. To enable theSerial number attribute, add the following entry in the collation.properties fileon the TADDM server:com.collation.discover.agent.sys.HpUxComputerSystemItaniumAgent.setSerialNumber=true

Hardware details are not displayed

ProblemDuring a discovery through IBM Tivoli Monitoring, certain detailedinformation is not displayed for computer systems running the HP-UXoperating system.


SolutionIn the collation.properties file, add the |.*machinfo.* pattern to theend of the property:com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*machinfo.*

IBM AIX computer system sensorThe IBM AIX computer system sensor discovers computer systems that run theIBM AIX operating system. In addition, workload partitioning (WPAR) in the IBMAIX 6.1 operating system is discovered by the sensor.



Prerequisites

The TADDM user must have access to the entstat command on AIX targetsystems.

Limitations



The sensor discovers WPARs by using the WPAR name and IP address. Afterrunning a discovery, if the IP address or name of WPAR has changed then clearthe topology data before running the discovery again. This task avoids thesituation, where duplicate WPARs with the same name exist in the database. Thislimitation does not apply to WPARs where the IP address is not configured.

The fully qualified domain name (FQDN) can be obtained for the WPAR from thehost name. In this case, TADDM does not request the host name from the DNSserver and the name is not displayed.



The discovered IPv6 addresses are displayed in the TADDM user interfacesimilarly to IPv4 addresses and are accessible using the TADDM API. Because IPv6addresses use a prefix length value instead of an IPv4 netmask, only one of these


values is populated for an IP address. The value depends on the address type.

Asynchronous and script-based discovery supportThe IBM AIX computer system sensor supports asynchronous and script-baseddiscovery.







Limitations

Some function that is provided by the AIX computer system sensor during anonscript-based discovery is not supported in an asynchronous or script-baseddiscovery.

Computer system templates and extensions are not supported.

The following attributes are not discovered:v Levelv BuildLevelv ServicePack

Model objects with associated attributesThe IBM AIX computer system sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout computer systems running the IBM AIX operating system and workloadpartitioning (WPAR) resources in your IT environment.


sys.aix.Aix

v AdminStatev Admininfov Descriptionv DisplayNamev Driversv InstalledSoftwarev LastModifiedByv Namev PatchesInstalled


v PrimaryOwner

sys.AixSoftwareComponent

v DisplayNamev Groupv LastModifiedByv LastModifiedTimev ManagedSystemNamev Namev Type

sys.aix.AixUnitaryComputerSystem

v Namev AdminStatev Admininfov CPUSpeedv CPUTypev LastModifiedByv LastModifiedTimev Manufacturerv MemorySizev Modelv Namev NumCPUsv PrimaryOwnerv Type

core.LogicalContent

v Checksumv Configfilev Contentv ContentTypev FixedPathv URI

core.Version

v BuildLevelv Levelv ServicePack

net.L2Interface

v AdminStatev Broadcastv ContextIpv Descriptionv DisplayNamev Duplexv Encapsulationv Guid


v HostInterfacev HwAddressv Labelv ManagedSystemNamev Mtuv Namev ObjectTypev Parentv Speed

dev.StorageExtent

v AdminStatev BasedOnv BlockSizev Capacityv ContextIpv Controllerv Descriptionv DeviceIDv DisplayNamev FreeSpacev ObjectTypev Parent

dev.StorageVolume

v AdminStatev BasedOnv BlockSizev Capacityv ContextIpv Controllerv Descriptionv DeviceIDv DisplayNamev FreeSpacev HostPathsv IOGroupv Labelv ManagedSystemNamev Namev NumOfBlocksv NumOfCylindersv ObjectTypev Parent

sys.WPARComputerSystem

v WparCPULimits


v WparCPUSharesv WparMemoryLimitsv WparMemorySharesv WparOwnerv WparPerProcessVirtualMemoryLimitv WparType


Edit the /etc/sudoers file on the AIX server and add the following line:<TADDM_USER> ALL=NOPASSWD: ALL


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

for either SSH key-based authentication or SSH login-based authentication tothe target computer system.

Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process can require privilegeescalation. This escalation, can be done using the sudo command.


Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the IBM AIX computersystem sensor uses.


com.collation.discover.agent.command.lswpar.AIX=sudo lswparThe lswpar command requires administration privileges.

com.collation.platform.os.command.crontabEntriesCommand.AIX=crontab -lThis property is used to discover crontab entries. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesCommand.AIX.1.2.3.4=crontab -l

com.collation.platform.os.command.crontabEntriesUsers.AIX=rootThis property is used to discover crontab entries for a specified user, use acomma-separated list to specify more than one user. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesUsers.AIX.1.2.3.4=root,build


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

Sensor does not discover WPARs

ProblemThe sensor is not able to discover WPAR.

SolutionTo check the status of the WPAR:1. Run the sudo lswpar command using the <TADDM_User> credentials.

If a list of WPARs is not displayed, assign to the <TADDM_User>administrator credentials to run the lswpar command.

2. Modify the sudo specific command in the collation.properties file.

Discovered WPARs do not display attribute values

ProblemSome of the discovered WPARs do not display attribute values.

SolutionVerify if the WPARs present are in an active or defined state. For WPARsthat are in a defined state, a limited number of attribute values aredisplayed.

IBM Hardware Management Console sensorThe IBM Hardware Management Console sensor discovers the IBM HardwareManagement Console (HMC) and its managed systems.


HmcSensor

Resources discovered by the sensor

The process for discovering an HMC is like discovering a standard computersystem. The most important issues that impact discovery is connectivity andauthentication. If the account configured in the TADDM access list can connect tothe HMC, the discovery is successful.

Through the HMC, the following resources can be discovered:v HMC, the hardware management console.v The systems managed by the HMC (System p® and System i® computer

systems).v The logical partitions (LPARs) defined within each managed system.v If an LPAR is installed with the Virtual I/O Server (VIOS), the VIOS is

discovered with minimal information.

Depending on the discovery scope, discovering a computer system (LPAR) canactually 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.


This instance is discovered just as a physical Linux or AIX computer system.There are no special TADDM sensors to discover these virtual computer systemsany differently than the physical computer systems they emulate.

The computer system (LPAR) discovered by the HMC is a shallow computersystem. The following key attributes, which form the naming rule, are discovered:v Manufacturerv Modelv Serial numberv LPAR ID

After discovery, TADDM merges the two instances into a single computer system.

VIOS is discovered with the following storage mapping information:v Virtual SCSI adaptersv Virtual NPIV adaptersv Virtual target devicesv Physical volumesv MPIO pathsv HBAs

You must use the Hmcoperator user to discover storage mapping information.

With the discovery of HMC and the storage sensor discovery of LPARs, you cansee a mapping between the LPAR disk and the virtual target device of a VIOS.

Limitations

To discover logical partitions (LPARs) and the HMC correctly, you must run theHMC sensor after a discovery of the LPARs.

Model objects with associated attributesThe IBM Hardware Management Console sensor creates model objects withassociated attributes. The attributes indicate the type of information that the sensorcollects about IBM Hardware Management Console (HMC) and its managedsystems in your IT environment.


dev.BasedOnExtent

v Sourcev Target

sys.ComputerSystem

v CPUCoresEnabledv CPUCoresInstalledv CPULimitv CPUSpeedv CPUTypev ChildSystemv ContextIp


v Descriptionv DesiredHugePagesv DesiredMemorySizev DesiredProcessingUnitsv DesiredProcessorsv Devicesv DisplayNamev FileSystemsv Fqdnv Functionsv Guidv HostSystemv IpInterfacesv IsVMIDanLPARv L2Interfacesv Labelv ManagedSystemNamev Manufacturerv MaxHugePagesv Memoryv MemoryLimitv MemorySizev MinHugePagesv Modelv Namev NumCPUsv OSInstalledv OSRunningv ObjectTypev PrimaryMACAddressv SerialNumberv Signaturev StorageExtentv SystemIdv Typev UncappedWeightv VMIDv Virtual

sys.ControlSoftware

v BuildLevelv ContextIpv DisplayNamev Fixesv Levelv MajorVersion


v Modifierv Namev Releasev VersionString

dev.FCPort

v DeviceIDv TotalNpivPortsv AvailableNpivPortsv Parentv Descriptionv PhysicalLocationCodev Statusv PermanentAddressv ChildPortsv SecondaryAddress

sys.FileSystem

v Parentv MountPoint

sys.Function

v Namev Parent

sys.HMC

v Systemp

sys.LocalFileSystem

v StorageExtent

dev.MediaAccessDevice

v Manufacturerv Modelv Namev SerialNumberv Statusv Type

dev.vios.MpioPath

v Controllerv Volumev Connectionv Status

dev.vios.NpivViosVirtualAdapter

v ClientStatusv FcPorts

dev.SCSIProtocolController

v Namev Parent


v PhysicalLocationCodev Clientv ServerSlotNumberv TargetDevicesv ClientSlotNumberv ObjectTypev Descriptionv EndPoints

dev.SCSIProtocolEndPoint

v Namev Parentv Description

app.SoftwareFix

v ControlSoftware

dev.StorageVolume

v Namev Parentv Typev IeeeUniqueVolumeNamev Capacityv LUNv Pvidv NumStalePartitionsv SerialNumberv SystemPStatev ViosUDIDv VolumeGroupNamev BasedOnv MpioPaths

sys.SystemPComputerSystem

v Architecturev AvailableSysProcUnitsv CPUCoresEnabledv CPUCoresInstalledv CPUSpeedv CPUTypev ConfigurableNumSysHugePagesv ConfigurableSysProcUnitsv ConfigurableSystemMemoryv DeconfiguredSysProcUnitsv DeconfiguredSystemMemoryv HugePageSizev Is5250ApplicationCapablev IsCoDMemoryCapable


v IsCoDProcessorCapablev IsI5OSCapablev IsLHCACapablev IsLHEACapablev IsMicroPartitioningCapablev IsSNIMsgPassingCapablev IsVIOSCapablev Manufacturerv MaxNumProcessorsPerLPARv MaxsSharedProcessorPoolsv MemoryAvailableForPartitionsv MemorySizev MinProcessingUnitsPerVirtualProcessorv Modelv SerialNumber

dev.vios.VirtualTargetDevice

v BackingDevicev Status



To configure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the following required information:

a. Username.This username should have (at a minimum) the authorizations mentionedbelow.

b. Password

From the HMC management console, create a user account for the TADDMdiscovery user. The user account must be based on the hmcoperator role.

In addition, the following command line tasks must be assigned to the useraccount:

Managed SystemRequired to use the lshwres and lssyscfg commands

Logical PartitionRequired to use the lshwres, lssyscfg, and viosvrcmd commands

HMC ConfigurationRequired to use the lshmc command


IBM Integrated Virtualization Manager sensorThe IBM Integrated Virtualization Manager sensor discovers IBM POWER®

processor-based systems managed by an Integrated Virtualization Manager (IVM).


IvmSensor

Resources discovered by the sensor

The process for discovering an IVM is like a standard computer system. The mostimportant issues that impact discovery is connectivity and authentication. If theaccount configured in the TADDM access list can connect to the IVM, thediscovery is successful.

Through the IVM, the following resources can be discovered:v The integrated management console.v The system managed by the IVM (System p or System i computer systems).v The logical partitions (LPARs) defined within the managed system.

Depending on the discovery scope, discovering a computer system (LPAR) canactually discover two instances of the computer system:v The computer system (LPAR) discovered by the IVM sensor.v The computer system discovered by the normal TADDM sensor for the

particular operating system, such as Linux or AIX, among others.

This instance is discovered just like a physical Linux or AIX computer system.There are no special TADDM sensors created to discover these virtual computersystems any differently than the physical computer systems they emulate.

The computer system (LPAR) discovered by the IVM is a shallow computersystem. The following key attributes, which form the naming rule, are discovered:v Manufacturerv Modelv Serial numberv LPAR ID, which are naming rule attributes.

After discovery, TADDM merges the two instances into a single computer system.


The sensor creates the following model objects:v sys.ComputerSystemv sys.ControlSoftwarev sys.IVMv sys.SystemPComputerSystemv sys.VIOS




To configure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the following required information:

a. User name.b. Password

From the IVM management console, create a user account for the TADDMdiscovery user with the View Only role.

IBM i computer system sensorThe sensor discovers the IBM i operating system, which is used on the IBM PowerSystems™ family of servers and is the next generation of the IBM i5/OS® operatingsystem and the IBM OS/400® operating system.



Prerequisites

The sensor requires the following software to be installed and operational:v IBM Portable Utilities for i, which provides OpenSSH and OpenSSL for IBM i.v Qshell, which is a standards-based command interpreter that enables a common

development environment.v Portable Application Solutions Environment (PASE), which includes three shells

(Korn, Bourne, and C Shell) and over 200 utilities that run as IBM i PASEprograms.

v The IBM Toolbox for Java, which is a library of Java classes that give Javaprograms easy access to the IBM i data and resources.

For IBM i 7.1, you need the following versions of the required software:v IBM Portable Utilities for i: 5733SC1 *BASE and option 1 (V7R1M0)v Qshell: 5770SS1 option 30v PASE: 5770SS1 option 33

Note: In IBM i 7.1, the licensed program product JC1 (IBM Toolbox for Java) is nolonger provided as a separate product. Instead, it is included as part of 5770SS1option 3.

For IBM i 6.1, you need the following versions of the required software:v IBM Portable Utilities for i: 5733SC1 *BASE and option 1 (V6R1M0)v Qshell: 5761SS1 option 30v PASE: 5761SS1 option 33v IBM Toolbox for Java: 5761JC1

For IBM i 5.4 and i5/OS V5R3, you need the following versions of the requiredsoftware:


v IBM Portable Utilities for i5/OS: 5733SC1 *BASE and option 1v Qshell: 5722SS1 option 30v PASE: 5722SS1 option 33v IBM Toolbox for Java: 5722JC1

Limitations



TADDM does not support the discovery of IBM i systems when using public keyinfrastructure (PKI) authentication. To initialize a connection between the TADDMserver and an IBM i system, you must use a user name and a password.


The sensor creates the following model objects:v core.LogicalContentv dev.MediaAccessDevicev sys.i5OS.I5OperatingSystemv sys.i5OS.I5OSSoftwareComponentv sys.i5OS.I5Profile


Sufficient access privileges are required that allow users to discover the system:v Privilege class: Userv System privileges:

– All object access is required to discover all user profiles on the system.– Save/restore

IPSO computer system sensorThe IPSO computer system sensor discovers Nokia firewall devices running theIPSO operating system.


IPSOComputerSystemSensor


Limitations




The sensor creates the following model objects:v core.LogicalContent net.Firewallv sys.Functionv sys.ipso.ipsov sys.ipso.IPSOUnitaryComputerSystem


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

use for either SSH key-based authentication or SSH login-based authenticationto the target system.

Linux computer system sensorThe Linux computer system sensor discovers computer systems running the Linuxoperating system.



Limitations








The sensor creates the following model objects:v core.LogicalContentv sys.linux.Linuxv sys.LinuxUnitaryComputerSystemv sys.SoftwareComponentv sys.zOS.ZSeriesComputerSystemv sys.zOS.LPARv sys.zOS.ZVMGuest

Asynchronous and script-based discovery supportThe Linux computer system sensor supports asynchronous and script-baseddiscovery.







Limitations

Some function that is provided by the Linux computer system sensor during anonscript-based discovery is not supported in an asynchronous or script-baseddiscovery.

The following functions are not supported:v Computer system templates and extensionsv Deep Level 2 discovery


v Discovery on Linux systems that are not x86 systems

The following attributes are not supported for the L2Interface model object:v AutoNegotiationv Speedv Duplex

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




Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process may require privilegeescalation (typically done using the sudo command).


Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Linux computersystem sensor uses.

The sensor uses the control program vmcp command to discover a Linux virtualsystem running on a z/VM® operating system. For each Linux virtual system,specify the path for the vmcp command in the collation.properties file.

com.collation.discover.agent.command.vmcp.Linux.1.2.3.4={command path}This value specifies the path name of the vmcp command for differentLinux virtual systems with different IP addresses. For example, to specifythe path of the vmcp command in the /sbin directory, on a Linux host withIP address 192.168.1.2, add the following entry to thecollation.properties file:com.collation.discover.agent.command.vmcp.Linux.192.168.1.2=sudo /sbin/vmcp

com.collation.platform.os.command.crontabEntriesCommand.Linux=crontab -l-u This property is used to discover crontab entries. You can specify this

property as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesCommand.Linux.1.2.3.4=crontab -l -u

com.collation.platform.os.command.crontabEntriesUsers.Linux=rootThis property is used to discover crontab entries for a specified user, use acomma-separated list to specify more than one user. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesUsers.Linux.1.2.3.4=root,build


Troubleshooting the sensorThis topic describes common problems that occur with the Linux computer systemsensor and presents solutions for those problems.

The sensor fails with a command failed to run error

ProblemThe following message is displayed:Error Message: CTJTD0431E: The following command failed to run or returnsa blank value: sudo /sbin/vmcp q userid | awk ’print{3}’.

The command vmcp q userid has failed to run or returns a blank value onthe target Linux virtual system running on a z/VM operating system.

SolutionThis problem is caused by one of the following conditions:v An incorrect path for the vmcp command on the target Linux virtual

system.v The vmcp tool is not installed on the target Linux virtual system.v The sudo command is not configured to run the vmcp command.v The system name is not configured on the z/VM system.

To solve this problem, complete the following steps:v Verify that the correct path for the vmcp command is entered in the

collation.properties file. See the topic “Configuring thecollation.properties file entries” for details.

v Verify that the system name is configured on the z/VM system, thesystem name cannot be blank.

v If the vmcp tool is not installed on the Linux virtual system, you mustload it. To load the vmcp device driver, issue the modprobe vmcpcommand on the Linux guest.

v Verify that the sudo command is available. To verify run the followingcommand on the Linux guest where the monitoring agent is installed:sudo vmcp q userid

If sudo is active and loaded, this command sends the q userid commandto the hosting virtual machine, which queries the user ID for the guest.If there is not a requirement to reconcile the Linux virtual system to thehost system on the z/VM operating system, it is not necessary to run thevmcp command. You can use the externalized command property(com.collation.discover.agent.command.vmcp.Linux=) in thecollation.properties file to set the host system value to a “dummy” value.You must be able to parse the externalized command with the followingcommand appended to it:q userid | awk ’{ print $3 }’

For example, you might use:com.collation.discover.agent.command.vmcp.Linux.192.168.1.2=echo A B zVMHost

This produces the echo A B zVMHost q userid | awk ’{print $3 }’which returns the zVMHost name. The host attribute for your virtualsystems is set to “zVMHost” instead of the actual host system name.


z/VM guests can be duplicated after multiple discoveries of thesame Linux virtual system

ProblemDuplicates can occur if the command vmcp q userid returns a blank valueon the target Linux virtual system running on a z/VM operating system.

SolutionYou must manually merge these duplicates.

OpenVMS computer system sensorThe OpenVMS computer system sensor discovers computer systems running theOpenVMS operating system.



Limitations




The sensor creates the following model objects:v core.LogicalContentv sys.openvms.OpenVmsv sys.openvms.OpenVmsUnitaryComputerSystem




Solaris computer system sensorThe Solaris computer system sensor discovers computer systems that are runningthe Solaris operating system.


If the target system is a Solaris 10 global zone that has local zones with a status ofrunning, the sensor creates a computer system object for each zone and populatesthe following attributes:v namev virtualv typev VMIDv host systemv signaturev processor name

To retrieve operating system details for the local zone, you must add the IPaddress of the local zone to the discovery scope.



Limitations



The sensor discovers the number of physical processors if one of the followingcommands are present on the target system:v psrinfo -p

v prtconf and kstat -m cpu_info. The kstat command must returnimplementation statistics.

The sensor discovers the number of processor cores when the command kstat -mcpu_info is present on the target system. The kstat command must return core_idstatistics.

For the sensor to discover information about promiscuous mode on the Solarisoperating system, the following command must be available for the networkinterface on the target system:kstat network_interface_name | grep promisc


The sensor discovers IPv6 interfaces and IPv6 routing and forwarding informationabout target systems that are configured to support IPv6. TADDM runs discoveriesagainst only IPv4 addresses. TADDM does not start a sensor against IPv6addresses. For DNS lookups, TADDM uses either the IPv4 or the IPv6 addresses.


TADDM does not populate the net.IpNetwork attribute on an IPv6 interface if theprefix length value is unspecified or equals zero.



The sensor creates the following model objects:v core.LogicalContentv sys.sun.Solarisv sys.sun.SolarisPackagev sys.SunSPARCUnitaryComputerSystem

Asynchronous and script-based discovery supportThe Solaris computer system sensor supports asynchronous and script-baseddiscovery.






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

Limitations

Some function that is provided by the Solaris computer system sensor during anonscript-based discovery is not supported in an asynchronous or script-baseddiscovery.

The following functions are not supported:v Computer system templates and extensionsv Deep Level 2 discoveryv Zone discovery

The following attributes are not supported:v L2Interface

– AutoNegotiation– Speed– Duplex

v ComputerSystem (global zone)– Virtual


– ChildSystem– VMID– CPUCoresInstalled– CPUDiesInstalled

v ComputerSystem (local zone)– Virtual– HostSystem– VMID– CPUCoresInstalled– CPUDiesInstalled

Configuring the sensorBefore running a discovery, you must configure the Solaris computer systemsensor.




Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process can require privilegeescalation (typically done using sudo command).


Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Solaris computer systemsensor uses.


com.collation.platform.os.command.crontabEntriesCommand.SunOS=crontab -lThis property is used to discover crontab entries. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesCommand.SunOS.1.2.3.4=crontab -l

com.collation.platform.os.command.crontabEntriesUsers.SunOS=rootThis property is used to discover crontab entries for a specified user, use acomma-separated list to specify more than one user. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesUsers.SunOS.1.2.3.4=root,build


Troubleshooting the sensorThis topic describes common problems that occur with the Solaris computersystem sensor and presents solutions for those problems.


ProblemThe TADDM discovery user does not have authority to run the pscommand with the full command-line arguments required to start thesensor.

SolutionComplete one of the following tasks:v Set the sticky bit for the ps command, using the following command:

chmod u+s /usr/ucb/ps

Note: The sticky bit might be overwritten by the operating system if apatch is applied that updates the ps command.

v Configure the ps command to run with sudo access for the TADDMdiscovery user by completing the following steps:1. Set the following properties in the $COLLATION_HOME/etc/

collation.properties file:– com.collation.platform.os.command.ps.SunOS=sudo /usr/ucb/ps

axww

– com.collation.platform.os.command.psEnv.SunOS=sudo/usr/ucb/ps axwweee

– com.collation.platform.os.command.psParent.SunOS=sudo ps-elf -o ruser,pid,ppid,comm

– com.collation.platform.os.command.psUsers.SunOS=sudo/usr/ucb/ps auxw

2. Ensure that sudo access has been granted to the TADDM discoveryuser by running the following command on the target system:sudo ps

Discovery fails when carrying out a discovery through IBM TivoliMonitoring

ProblemDuring a discovery through IBM Tivoli Monitoring, the discovery failsbecause of a problem running the command cd $HOME;LANG=C zonecfg -zs8-zone info.

SolutionIn the collation.properties file, add the |.*zonecfg.* pattern to theend of the property:com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*zonecfg.*

Solaris zones generic sensorThe Solaris zones generic sensor discovers applications running on Solaris localzone systems.

The sensor results are used to start specific application sensors, such asIplanetServerSensor, WeblogicServerSensor, or CustomServerSensor, which discoverapplication servers that TADDM does not automatically categorize.


This sensor uses a discovery approach that is different from other UNIX systems.Rather than running a discovery against local zone systems directly, a global zonesystem is used to start the ZonesGenericSensor. This is because the lsof tool isunavailable on local zones. To retrieve all operating system details of the localzone, you must include the IP address of the local zone in the discovery scope.


ZonesGenericSensor

Prerequisites

The credentials for local and global zones must be entered in the access list (eitherusing SSH key-based authentication or SSH login-based authentication).

Security issues

To correctly discover applications running on a local zone, the TADDM serviceaccount in the local and global zones must have access to the ps command withfull command-line arguments.

Use the following method, to ensure access when the root account or the setuidbit are not used. Modify the following properties in the $COLLATION_HOME/etc/collation.properties file to configure the ps command to use sudo:

v com.collation.platform.os.command.ps.SunOS=sudo /usr/ucb/ps axww

v com.collation.platform.os.command.psEnv.SunOS=sudo /usr/ucb/ps axwweee

v com.collation.platform.os.command.psUsers.SunOS=sudo /usr/ucb/ps auxw

Limitations

Note the following limitations:v The sensor does not create ProcessFileSystemMapping objects for local zones.

When a process running on a local zone uses an NFS share, the dependencybetween the application server and the NFS Server is not created.

v When WebLogic 8 (all releases) managed and admin servers are running on localzones, the runtime information is stored using the CustomAppServerSensor. TheCustomAppServerSensor is started by the WeblogicVersionSensor. You mustinclude all local and global zone IP addresses in the discovery scope. Inaddition, ensure that the custom server list contains at least one template tomatch the WebLogic command line and that the custom server is enabled.

v When running a discovery through an anchor server, include the IP addresses ofthe local and global zones in the same scope set as the anchor.

v Internet Protocol version 6 (IPv6) is not supported when running a discovery ona local zone.


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

Sun Fire SysControl sensorThe Sun Fire SysControl (SC) sensor discovers domains that are configured on SunFire systems.


The following information is obtained from the system controller on the Sun Firesystem:v Remote configuration administration operationsv Board assignments and board statusv Current® usage statistics for Capacity on Demand (COD) resourcesv System board devices and resource usage informationv System controller (SC) failover status or rolev Platform type, board available component list, the domain state for each domain,

and Capacity on Demand (COD) information


SysControlSensor

Security issues

The TADDM service account must have platform administrator privileges, whichmeans that the account is a member of the UNIX group platadmn. Any user whois a member of the platadmn group has privileges to run the following SystemManagement Services (SMS) commands:v rcfgadm

v showboards

v showcodusage

v showdevices

v showfailover

v showplatform

Model objects with associated attributesThe Sun Fire SysControl (SC) sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout domains that are configured on Sun Fire systems in your IT environment.


phys.physpkg.Board

v DisplayNamev Namev PhysicalPackagev RelativePosition

sys.sun.DynamicSystemDomain

v Boardv DisplayNamev Fqdnv HostSystemv IsVMIDanLPARv Modelv Namev NumCPUs


v SerialNumberv Typev Virtual

sys.sun.SunFireComputerSystem

v ChildSystemv Devicesv DisplayNamev Manufacturerv Modelv Namev SerialNumberv Type



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


An account with platform administrator privileges must be used.



com.collation.discover.agent.path.SunOSThis value specifies the path configuration for running commands.

The following commands are the System Management Services (SMS)commands that run:v rcfgadm

v showboards

v showcodusage

v showdevices

v showfailover

v showplatform

If the commands are in the opt/SUNWSMS/bin directory, for example, enterthe following command on one line:com.collation.discover.agent.path.SunOS=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/sbin:/sbin:/opt/SUNWSMS/bin

com.collation.discover.agent.SysControlAgent.timeout=1200000This value specifies the time interval in milliseconds to allow the commandto run.


Troubleshooting the sensorThis topic describes common problems that occur with the Sun Fire SysControl(SC) sensor and presents solutions for those problems.

Sensor fails with a timeout error

ProblemDuring a discovery, the sensor fails with a timeout error.

SolutionIn the etc/collation.properties file, add the following property, wherevalue is the number of milliseconds allowed for the sensor to run:com.collation.discover.agent.SyscontrolAgent.timeout=1200000

Increase the value, until the sensor no longer fails with a timeout error.

The sensor fails with a getModelObject error

ProblemThe following message is displayed:Error Message: CTJTD3021E: The sensor fails in a remote server:discoverSystemController: getModelObject failure

SolutionIn the etc/collation.properties file, add the path configuration forcommand execution (for example, /opt/SUNWSMS/bin):com.collation.discover.agent.path.SunOS=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/sbin:/sbin:/opt/SUNWSMS/bin

Tru64 computer system sensorThe Tru64 computer system sensor discovers computer systems running the Tru64UNIX operating system.



Prerequisites

The sensor requires the following software:v sudo command toolv lsof diagnostic tool

Install both tools in the same path as defined in the access list for accessing theTru64 UNIX computer system. This installation must be done on each Tru64 UNIXcomputer system to be discovered. The most tested versions are sudo-1.6.8p9 andlsof-4.78, however, other versions are likely to work, except in the case where thespecific package does not support Tru64 UNIX. To get sudo-1.6.8p9 andlsof-4.78, go to the following Web sites:v For sudo-1.6.8p9: http://www.gratisoft.us/sudo/download.htmlv For lsof-4.78: http://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 aparticular package has restrictions, TADDM is affected by those restrictions.


http://www.gratisoft.us/sudo/download.html

http://freshmeat.net/projects/lsof/?branch id=6029&release id=19567

http://freshmeat.net/projects/lsof/?branch id=6029&release id=19567

Limitations




The sensor creates the following model objects:v core.LogicalContentv sys.ComputerSystemv sys.tru64.Tru64


Configuring non-root user to run the sensorYou must add the users credentials for non-root users.

Edit the /etc/sudoers file on the Tru64 UNIX computer system and add thefollowing line, where non-rootuser is the user that runs the command:<non-rootuser> ANY = NOPASSWD: /sbin/hwmgr

The /etc/sudoers must reside on the Tru64 UNIX computer system that is beingdiscovered.

For example, to enable the user taddmusr to run the command on any Tru64 UNIXcomputer system, enter the following line:taddmusr ANY = NOPASSWD: /sbin/hwmgr

For example, to enable the user taddmusr to run the /sbin/hwmgr command on aspecific target system named target, enter the following line:taddmusr target = NOPASSWD: /sbin/hwmgr

Two commands must be located in the default location on the Tru64 UNIXcomputer system: /sbin/hwmgr and /usr/sbin/ifconfig.





Typically, an account with non-root privilege can be used. The commands that areused by the Tru64 computer system sensor carrying out the discovery can requireprivilege escalation. Typically, this escalation is done by setting the file accesspermissions using the sudo command.


Troubleshooting the sensorThis topic describes common problems that occur with the Tru64 computer systemsensor and presents solutions for those problems.

Storage error messages displayed

ProblemStorage error messages.

SolutionIn this case, the Tru64 UNIX system issues a message with an Other IPDevice status. Check the locations and permissions on the dependenciesand run the discovery again.

VMware ESX computer system sensorThe VMware ESX computer system sensor discovers VMware ESX servers.



Elements discovered by the sensor

Discovering the VMware ESX server (host machine) runs as it does for any otheroperating system. The most important issues that impact discovery is connectivityand authentication. If the account configured in the TADDM access list can connectto the VMware ESX server target, the discovery is successful.

For VMware ESX 2.5, discoveries are launched using commands. For VMware ESX3.0 and 3.5, commands are run over ssh and VMware APIs are used to getVMware ESX attributes and details about virtual machines.

Discovering the Virtual Machines (guest machines) actually discovers two instancesof a VM, a physical instance and a virtual instance. After discovery, TADDMmerges these two instances. The result is a single instance with all the attributes ofa physical machine, but with the indication that it is virtual. In the XML output ofthe database, this output is represented by an attribute such as:<virtual>true</virtual>

In the Discovery Management Console, a VM (virtual machine) is represented by acomputer system icon that is blue and transparent.

The physical instance is discovered by the normal TADDM sensor for theparticular guest operating system, such as Linux. It is discovered just like a


physical machine, which includes finding typical devices and attributes. No specialTADDM sensors are required to discover these virtual machines any differentlythan the physical machines they emulate.

The virtual instance is discovered by the VMware ESX sensor. It primarily usesconfiguration files (.vmx) and commands on the VMware ESX server to discover ashallow instance with data that can be described as the following:v Attribute data required to match naming rules and create a valid stand-alone

VM instancev Certain basic information that the VMware ESX server provides through the

vmware-cmd command.v An attribute (primaryMACAddress) that is used to reconcile the shallow virtual

instance with any physical instance that can be discovered.

There are two user scenarios for a VM discovery:v All-inclusive: When discovering a scope that includes the server and physical

instances, everything works as expected.The result is a virtual instance that shows up in the appropriate domain tomatch its domain name. This virtual instance is populated with all the attributesthat a similar physical machine would have.In addition, it has data and relationships regarding the host ESX server, a virtualattribute that gets set to true, and a VMID attribute that gets set to the onespecified in the .vmx configuration file. As long as the TADDM server hasconnectivity and authentication to the VM, this scenario does not present anyproblems.

v VM-only: When discovering a scope that contains only the VM, it shows up as aphysical machine with typical attributes, except that VMware intentionallyoverrides some model and manufacturer data.Therefore, it is possible to determine if a machine is virtual by examining someattributes. However, the icon is the one used for physical computers, and thevirtual attribute is not set to true.

To ensure all FQDN information about a VM is collected, you must have VMwareTools installed on the VM.

Prerequisites

For VMware ESX server version 3 and 4, the web Access service (servicevmware-webAccess) must be running on the target and the port that it runs on mustbe 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-rootTADDM service account in the VMware ESX console or use the root user fordiscovery.

For more information see the VMware community board: http://www.vmware.com/community/thread.jspa?messageID=454784


Limitations

VMware vCenter servers are not discovered by the VMware ESX computer systemsensor. If you must discover these servers, use the VMware Virtual Center serversensor.



For VMware ESX server version 2.5 (all releases), you can discover virtual systemsonly that are running.


The sensor creates the following model objects:v core.LogicalContentv net.IpInterfacev net.L2Interfacev process.CPUResourcePoolv process.MemoryResourcePoolv process.NetworkAdapterResourcePoolv relation.AllocatedTov relation.DonatedTov sys.CPUv sys.darwin.Darwinv sys.darwin.DarwinUnitaryComputerSystemv sys.dos.Dosv sys.dos.DosUnitaryComputerSystemv sys.DNSResolveEntryv sys.FileSystemv sys.freebsd.FreeBSDv sys.freebsd.FreeBSDUnitaryComputerSystemv sys.linux.Linuxv sys.linux.LinuxUnitaryComputerSystemv sys.Memoryv sys.netware.Netwarev sys.netware.NetwareUnitaryComputerSystemv sys.OperatingSystemv sys.sun.Solarisv sys.sun.SunSPARCUnitaryComputerSystemv sys.UnitaryComputerSystemv sys.vmware.VmwareESX


v sys.vmware.VmwareUnitaryComputerSystemv sys.windows.WindowsComputerSystemv sys.windows.WindowsOperatingSystem


Configuring non-root user to run the sensorYou must add the users credentials to the Read-Only role by using the VMwareInfrastructure 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 theRead-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.






com.collation.platform.os.command.osVersion.VmwareThe command used to determine the version of VMware. The defaultvalue is /usr/bin/vmware –v.

com.collation.platform.os.command.vmwareCmdThe command to perform operations on the virtual machine. The defaultvalue is /usr/bin/vmware-cmd.


Troubleshooting the sensorThis topic describes common problems that occur with the VMware ESX computersystem sensor and presents solutions for those problems.

Some attribute information is not displayed in the Details panelof the VMware server

ProblemThe attributes Model, Manufacturer, and Serial Number are blank in theDetails panel of the VMware ESX server. (VMware ESX 2.x only)

SolutionThe dmidecode command is not installed or not working properly. Thiscommand for the Linux kernel operating systems is not installed by defaulton 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 thedmidecode command installed on the VMware ESX server. For moreinformation see: http://www.nongnu.org/dmidecode/.

Duplicate VMs are created

ProblemAfter discovery, certain VMs seem to have duplicates.

SolutionTADDM discovers two instances of a VM, one physical and one virtual. Ifthey cannot be reconciled to the same specific machine, two instances canexist in the database with similar attributes. These are not duplicates, buttwo separately discovered instances of the same VM.

This distinction is key to troubleshooting the problem, and there areseveral things to check, starting with TADDM, moving into the VMwareenvironment, and then finally troubleshooting the general networkenvironment.

Issues related to a pre-existing instance or databaseThe first item to check when troubleshooting a reconciliationproblem is the database. If the VM has made the transition to anew VM, the old VM might not be able to reconcile.

The old instance can be deleted, preferably before restarting thediscovery. If multiple runs are necessary to try different solutions,remember to delete all instances of the existing VM in advance.

It can also help to delete the instance of the host ESX server. If it isfeasible in the environment, it can be helpful to drop and re-createthe TADDM database between discovery runs. Then run a newdiscovery and see if the duplicates still exist.

<primaryMACAddress> attributeThe main reason that two instances of a VM cannot be reconciledis that they have different values in the <primaryMACAddress>attributes. To determine this value for each instance, it is necessaryto export the objects of type ComputerSystem from the TADDMdatabase with the following command run on the TADDM server:

Non-Windows:$COLLATION_HOME/sdk/bin/api.sh -u <username> -p <password>

find --depth 1 ComputerSystem > <filename>.xml


Windows:%COLLATION_HOME%\sdk\bin\api -u <username> -p <password>

find --depth 1 ComputerSystem > <filename>.xml

An XML file that lists the first-level attributes for allinstances of the ComputerSystem class is generated. Lookfor the short name of the duplicate instances and scrolldown to the attribute named <primaryMACAddress>.

If the value is different for the two instances, it is necessaryto troubleshoot the MAC address assignments in theconfiguration file on the server, on the VM itself, or both.

VM configurationIf a VM is configured in NAT or 'host only' mode, the VMwareESXsensor discovers the virtual instance, but the physical instance isnot discovered.

VM configuration files on the ESX host serverThe TADDM VMwareESX sensor gathers information fromconfiguration files for each VM to be discovered. Theseconfiguration files can be located with the following ESXcommand:vmware-cmd –l (this is a lower-case ’L’)

This command lists the configuration file for each VM known tothe ESX server, indicated by the .vmx extension.

These files are in XML format and are not case-sensitive. View theinformation in the configuration file for the VM that has duplicateinstances.

Validate the information for each interface to ensure that the MACaddress for each line corresponds to an interface on the VM itself.ethernet0.present = "true"ethernet0.networkName ="VM Network"ethernet0.addressType = "generated"ethernet0.generatedAddress="00:0c:29:c1:a5:ee"ethernet0.generatedAddressOffset = "0"ethernet1.present = "true"ethernet1.networkName = "VM Network"ethernet1.addressType = "generated"ethernet1.generatedAddress="00:0c:29:c1:a5:f8"ethernet1.generatedAddressOffset = "10"

If the values are different in the configuration file or on the VM,correct them and try the discovery again.

Configuration on the VM itselfOn the VM, there is a command that displays the information foreach networking interface.

On non-Windows systems, the command is ifconfig. On Windowsthe command is ipconfig.

Examine the output and validate the interface/MAC pairingsagainst the ESX configuration file. You can also verify that eachinterface is working by pinging the associated IP address. Try thediscovery again.


Recent changes in a VM or movement from one ESX server to anotherIf a VM has been migrated from one ESX server to another, it ispossible that the configuration file was changed and that can affectdiscoveries.

If the lines that contain generatedAddress get deleted it can affectdiscoveries.

When migrating VMs in a VirtualCenter environment, any VMwith a generated MAC address is going to change it. If there is anexisting VM on the ESX server that can be successfully discovered,use the configuration file for that VM as an example and look forany lines that might have been deleted.

The ESX server where the VM originated can also be specified as atarget in a scope to see if the VM discovers correctly on that ESXserver. If there are lines that have been deleted or modified duringmigration, add or correct them and run the discovery again.

Name resolutionIf the VM cannot resolve to a single machine on the network, it canend up in TADDM as two separate instances. If the VM hasmultiple interfaces, and all interfaces are visible on the network,multiple valid instances can be found. It might not be possible tomerge all instances into a single instance.

This is typically caused by a mismatch between hosts files, DNS,NIS, or any other name resolution service.

The remedy is to test the name resolution by the machine shortname a few times from the VM itself, the ESX server, and theTADDM server. All the responses must match. If they returndifferent responses, modify the name service or hosts files until theresults are consistent. Try the discovery again.

General network connectivity & routingThere are global networking factors to consider in troubleshootingTADDM discoveries. As it relates to VMware discoveries, a firewallor other networking consideration such as SSH might partiallyobscure discovery of either the ESX server or the VM.

If the VM is discovered correctly by the VMware sensor, it isdisplayed with only a short name label under the PhysicalInfrastructure: Overview > Systems Tier > Virtual Systems >VMware ESX

The VM itself appears only as an object under the heading ofOther Ip Device or Other Computer System.

In the case where only the VM is discovered correctly by the OSsensor, it is displayed as the appropriate type of Computer System.The virtual instance is not displayed, and the ESX server might notbe displayed either.

Correct the routing and firewall configuration until the TADDMserver can ping and SSH to the ESX server and directly to each ofthe VMs, then try the discovery again.

Duplicate VMware ESX servers are created

ProblemVMware ESX servers (Version 2.5 (all releases)) seem to be duplicated. This


problem occurs when a sequential discovery is run by using the VMwareESX computer system sensor followed by the VMware Virtual Centerserver sensor.

SolutionYou must manually merge duplicated VMware ESX servers.

The TADDM User's Guide (or the TADDM “Using” topics) containsinformation about using the Data Management Portal, includinginformation about discovery tasks, and how to manually merge discoveredconfiguration items.

VMware ESX server configuration items (CIs) are missing

ProblemThe CI for the VMware ESX servers are missing or show erroneousinformation such as processor and memory information.

SolutionFor VMware ESX server version 3 and 4, ensure that the web Accessservice (service vmware-webAccess) is running on the target. The port thatit runs on must be accessible from the discovery server or its anchor.

Windows computer system sensorThe Windows computer system sensor discovers computer systems runningMicrosoft Windows operating systems.



Prerequisites

For discovery using a gateway, the gateway must be accessible through SSH.

To discover Windows systems without using a gateway:v The Windows systems must be accessible through SSH.v Microsoft .NET Framework 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 6Service Pack 1 or higher.

Limitations








The sensor creates the following model objects:v dev.MediaAccessDevicev sys.DNSResolveEntryv sys.SoftwareComponentv sys.windows.WindowsComputerSystemv sys.windows.WindowsOperatingSystemv sys.windows.WindowsService

Configuring the sensorBefore using the Windows computer system sensor, you must configure it.

Complete the following setup:v Install all required software.v For discovery using a gateway, WMI must be enabled on all target Windows

systems. WMI is enabled by default.By default, discovery using a gateway automatically installs the TADDM WMIProvider on all target Windows systems during the discovery process.


To configure the access list, complete the following steps:1. For full discovery of Windows hosts and software, each Windows machine

requires a service account in the local admin group with WMI access to allWMI objects on that machine. This account can be a local account or a domainaccount.The service account must be created on the Windows gateway and all targetWindows computer systems.

2. Access list entries must be created for the Windows computer systems (gatewayand the target Windows systems).When specifying a Windows domain user account for an access list entry, thedomain name and user name must be separated by a backslash (\) as shown inthe following example: DOMAIN\username.


3. TADDM also supports SNMP-based discovery of Windows systems. To supportSNMP-based discovery, complete the following steps:a. Enable SNMP.b. Ensure that the SNMP MIB2 GET Community string has access permission

for MIB2 System, IP, Interfaces, Extended Interfaces, and Host Resources.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Windows computersystem sensor uses.

Gateway-based or SSH-based discovery properties

com.collation.AllowPrivateGateways=trueThe default value is true.

This property specifies whether a Windows computer system can bediscovered using SSH or IBM Tivoli Monitoring connections withoutrequiring an intermediate gateway. The default is to allow SSH or IBMTivoli Monitoring connections to Windows systems. If the value is set tofalse, only gateway-based discovery can be used.

com.collation.PreferWindowsSSHOverGateway=falseThe default value is false.

This property specifies whether to use SSH rather than gateway-baseddiscovery if a Windows computer system supports SSH. Even if aWindows computer system supports SSH, the default value for thisproperty indicates that gateway-based discovery is used. This property isignored if com.collation.AllowPrivateGateways=false.

WMI-related properties

TADDM relies on Windows Management Instrumentation (WMI) to discoverWindows computer systems. TADDM can be configured to restart the WMI serviceif a problem occurs with WMI. If the WMI service is restarted, all WMI-dependentservices that were running before the restart are also restarted.

com.collation.platform.os.WindowsOs.AutoDeploy=trueThe default value is true, which indicates that TADDM can automaticallyinstall the WMI provider.

Setting the value to false indicates that you can manually deploy the WMIprovider. Manual deployment is not supported but can be used fortroubleshooting.

The following TADDM server properties control the restarting of WMI.

Note: The default value for WMI restart is false. Setting the values of thefollowing properties to true might provide more reliable Windows discovery, butyou must also consider the potential negative impact of the WMI service beingtemporarily stopped and restarted.

com.collation.RestartWmiOnAutoDeploy=falseRestart WMI if a WMI error occurs during automatic deployment of theTADDM WMI Provider.

com.collation.RestartWmiOnAutoDeploy.1.2.3.4=falseRestart WMI if a WMI error occurs during automatic deployment of theTADDM WMI Provider.


com.collation.RestartWmiOnFailure=false

Restart WMI if a WMI error occurs, except during automatic deployment.

com.collation.RestartWmiOnFailure.1.2.3.4=false

Restart WMI if a WMI error occurs, except during automatic deployment.

Troubleshooting the sensorThis topic describes common problems that occur with the Windows computersystem sensor and presents solutions for those problems.

Problem with WMI

ProblemWindows Management Instrumentation (WMI) fails on the system that isto be discovered, which causes discovery to fail.

SolutionRestarting WMI might correct the problem. Use the following commandsto restart WMI:net stop winmgmtnet start winmgmt

If restarting WMI does not correct the problem, use the following Microsoftutilities to troubleshoot WMI problems:

WMIDiagThe WMIDiag utility is available at the following Web site:http://www.microsoft.com/downloads/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en

Follow the instructions to install and run the utility, and verify thatWMI is working correctly.

ScriptomaticThe 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 thatare similar to those used by TADDM. The following WMI classesare some that TADDM queries:v Win32_Processv Win32_OperatingSystemv Win32_WMISettingv Win32_ComputerSystem

Verify that these classes can be queried using the Scriptomaticutility locally on the target system and remotely from the gateway.

Problem with deployment of WMI provider

ProblemFor discovery of Windows systems, TADDM deploys a WMI provider toeach target system to enable agentless discovery. Sometimes, problemsoccur with this deployment.





http://www.microsoft.com/downloads/details.aspx?familyid=09dfc342-648b-4119-b7eb-783b0f7d1178&displaylang=en



SolutionThe following files comprise the WMI provider and are located on theTADDM server in the $COLLATION_HOME/lib/ms/gateway directory:

TaddmWmi.dllThe WMI provider, which runs TaddmWmi.exe for functionality

TaddmWmi.mofSpecifies the new WMI methods that are provided by the WMIprovider (TaddmWmi.dll)

TaddmWmi.exeCalled by the WMI provider (TaddmWmi.dll) to run a command

TaddmWmi.pdbContains debugging information for the TaddmWmi.dll file

The TADDM WMI installation provider performs the following tasks:1. As applicable, copies the files in the preceding list to the following

directory on each target system that is in the discovery scope (it useseither the Admin$ or C$ directory to do this): %SystemRoot%\System32\wbem

2. Runs the following commands on each target system:

On 32-bit Windows operating systems:%SystemRoot%\System32\wbem\mofcomp.exe %SystemRoot%\System32\wbem\TaddmWmi.mof%SystemRoot%\System32\regsvr32 /s %SystemRoot%\System32\wbem\TaddmWmi.dll

On 64-bit Windows operating systems:%SystemRoot%\SysWOW64\wbem\mofcomp.exe %SystemRoot%\SysWOW64\wbem\TaddmWmi.mof%SystemRoot%\SysWOW64\regsvr32 /s %SystemRoot%\SysWOW64\wbem\TaddmWmi.dll

To troubleshoot WMI or access-related problems, you can run the TADDMWMI installation provider manually. To manually install the provider usingthe TaddmTool program on the Windows gateway, enter the followingcommands:1. cd WINDOWS\temp\taddm.nnnn, where nnnn is a string that identifies the

TADDM gateway directory. If fixes have been applied to the TADDMserver, more than one gateway directory might be present. Theidentifier string can be found in the DiscoveryManager.log file after thefollowing item: DTADDM_ID=

2. set TADDM_USERNAME=domain\userid

3. set TADDM_PASSWORD=password_for_userid

4. set TADDM_INTERACTIVE=1

5. TaddmTool InstallProvider -AutoDeploy @ipaddress, where ipaddress isthe IP address of the target system

WMI access denied errors

ProblemYou have WMI access denied errors.

SolutionRefer to Appendix F of the Deployment Guide Series: IBM Tivoli Change andConfiguration Management Database Configuration Discovery and Tracking v1.1,an IBM Redbooks® publication, at http://www.redbooks.ibm.com/abstracts/SG247264.html.


WMI process creation errors

ProblemWMI process creation fails with an access error during providerinstallation. There might be a problem with the Windows Replace aProcess Level Token privilege not being granted to the required accounts.

Solution

v This privilege should be granted to the LOCAL SERVICE andNETWORK SERVICE accounts. To verify this, complete the followingsteps:1. Log onto the target machine using the console or the Terminal Server

Client.2. Click Start.3. Select Run.4. Enter gpedit.msc to start the Group Policy editor.5. Descend down the tree of privileges under Local Computer Policy >

Computer Configuration > Windows Settings > Security Settings >Local Policies > User Rights Assignment.

v If you cannot change the accounts assigned to the Replace a ProcessLevel Token privilege, try to add the discovery account to a group thathas that privilege.Check to see if the Tivoli_Admin_Privileges group has the privilege. Ifit does, make the discovery account a member of that group.

The specified network name is no longer available

ProblemIf this error occurs, or if there is a problem copying files to the targetduring provider installation, there might be a problem connecting to theSMB (file sharing) service on the target machine.

Solution

Complete the following steps:1. Check to see if an SMB port is listening.

v Windows 2003 will listen on port 445.v Windows 2000 may listen on either 445 or 139.

2. On the gateway, check to see if a connection is allowed or refused byopening a command window and running the following command:telnet <target machine name> 445

3. If it is refused, repeat step b using port 139. If both fail, you have oneof the following issues:v There is a firewall preventing the gateway from connecting to the

target SMB service.v The SMB service is not running or otherwise not functional.

To determine whether the cause is a firewall or the SMB service, completethe following steps:1. Log onto the target machine through the console or the Terminal Server

Client.2. Run the telnet commands in steps 2and 3 above, where this time

<target machine name> is the local machine.


If telnet succeeds, a firewall is causing the problem. Otherwise, there isa problem with the SMB service.

Do the following:v View the control panel, services, and check if the Server service is

running.v Run the following command at the command line:

net share

One of the shares: c$ or admin$ must exist.

Slow discovery of Windows 2003 SP1 systems, or applicationsrunning on those systems

ProblemThe slow discovery of Windows 2003 SP1 systems, or applications runningon those systems, might be a result of a memory leak in the WMI service.

SolutionEnsure that the following hotfix, available from Microsoft, is installed:http://support.microsoft.com/kb/911262

Windows 2000 systems are not discovered

ProblemIf Windows 2000 systems are not discovered, the problem might bebecause an unsupported version of the netstat program installed on thetarget system. The netstat program is used to get TCP port informationduring discovery. Windows 2000 systems use a different version of thenetstat program from the one installed on systems running later versionsof Windows.

SolutionEnsure that the following hotfix, available from Microsoft, is installed:http://support.microsoft.com/kb/907980


http://support.microsoft.com/kb/911262

http://support.microsoft.com/kb/907980

Chapter 7. Storage sensors

Storage sensors discover the storage that is used in the environment.

Fibre Channel switch sensorThe Fibre Channel switch sensor discovers Fibre Channel (FC) switches andinformation about FC ports.


FCSwitchSensor

Model objects with associated attributesThe Fibre Channel (FC) switch sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout Fibre Channel switch resources in your IT environment.


dev.FCPort

v DisplayNamev PortNumberv DeviceIDv PermanentAddressv PortTypev Speed

relation.ConnectedTo

v Sourcev Target

storage.FCSwitch

v Namev Descriptionv WorldWideNamev Modelv Manufacturerv SerialNumberv Version

sys.ControlSoftware

v Namev VersionString




The sensor is not enabled by default. To enable the sensor, you must create adiscovery profile, and then enable the sensor from the new profile. The sensorrequires, additional sensors to be enabled in the profile:v AnchorSensor

v PingSensor

v PortSensor

v SessionSensor

v SnmpMib2Sensor










Troubleshooting the sensorThis topic describes common problems that occur with the Fibre Channel switchsensor and presents solutions for those problems.

Incomplete switch information discovered

ProblemThe sensor completes the discovery but does not collect all the detailsabout the switches.

SolutionVerify that the following data is available:v Fibre Alliance MIB (FC-MGMT MIB)v Cisco MIB (CISCO-FC-FE MIB)v Brocade switch model information (switch.html)


Host resources sensorThe host resources sensor uses the host resources MIB to discover operating systemdetails such as memory size, file system, installed software with date and type,Media Access Device, and logical storage areas.

Details about the logical storage areas can be useful for troubleshooting “out ofmemory” and “out of buffers” problems.


HostResourcesSensor

Limitations

File systems discovered by the sensor are not displayed in the user interface. Thisrestriction applies to computer systems running on operating systems other thanWindows operating system. Run the api.sh script to see the file systemsdiscovered by this sensor.


The sensor uses the following high-level OIDs to retrieve the attributes:v Memory Size: .1.3.6.1.2.1.25.2.2.0v Storage Table: .1.3.6.1.2.1.25.2.1.2v Device Type: .1.3.6.1.2.1.25.3.1.1v Media Access Device: .1.3.6.1.2.1.25.3.2.1.1v Installed Software: .1.3.6.1.2.1.25.6.3.1.1


The sensor creates the following model objects:v dev.MediaAccessDevicev sys.ComputerSystem sys.OperatingSystemv sys.FileSystemv sys.SoftwareComponent







Chapter 7. Storage sensors 269





Host storage sensorThe host storage sensor discovers the storage that is attached to a host computersystem, including storage area network (SAN) storage. This sensor extends thestorage discovery that is provided by the storage sensor.

The host storage and storage sensors discover the same storage resources, forexample, disks, partitions, logical volumes, physical volumes, and file systems. Thehost storage sensor also discovers the following storage resources:v Fibre Channel (FC) volumesv FC portsv Host bus adapters


HostStorageSensor

Security issues

By default, root user privileges are required to discover SAN resources in UNIXenvironments. Typically, this escalation is done by setting the file accesspermissions using the setuid (set-user-ID mode bit) term or by using the sudocommand.

Model objects with associated attributesThe Host storage sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about storageresources in your IT environment.


dev.DiskDrive

v AnsiT10Idv Namev Type

dev.DiskPartition

v BlockSizev Namev NumOfBlocks

dev.FCPort

v DeviceIDv PermanentAddressv PortType


v Speed

dev.FCVolume

v BlockSizev Controllerv DeviceIDv FCPLunv Namev NodeWWNv NumOfBlocksv PortWWNv SCSIBusv SCSILunv SCSITargetv Type

dev.SCSIProtocolController

v EndPointsv FCPortsv Name


v Namev WorldWideName

dev.SCSIVolume

v BasedOnv BlockSizev DeviceIDv Namev NumOfBlocksv SCSIBusv SCSILunv SCSITargetv Typev RealizedBy

dev.StorageVolume

v BasedOnv BlockSizev DeviceIDv Namev NumOfBlocksv RealizedByv Type

storage.HostBusAdaptor

v Namev SCSIProtocolControllersv WorldWideName



Copying the collection engine file to a location accessible to thetarget host systemThe Host storage sensor uses an executable program, the collection engine file todiscover storage data. By default, the Host storage sensor copies the collectionengine file, to a location on the target host system. After the discovery is complete,the collection engine file is deleted from the host. Root privileges are required torun the collection engine program. Copying an application to a host system thatrequires root privileges can introduce a security risk. To avoid this risk, the sensorsupports a configuration that allows the collection engine to be deployed to, andaccessed from, a secure location.

To run the collection engine from a secure location, copy the collection engine fileto a location that is accessible to the target host system.

To copy and configure the collection engine file, complete the following steps:1. From the taddm_home/dist/osgi/plugins/

com.ibm.cdb.discover.sensor.dev.hoststorage_7.2.0/bin/collection-enginedirectory on the TADDM server, copy the file to a location that is accessible tothe target host system.

2. Restrict ownership and access to the directory to user root.3. Specify the location of the collection engine file. The location must be accessible

from the target host system. To specify the location of the collection engine file,use one of the following options:v For Windows systems, edit the System PATH environment variable on 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 thecollection engine directory. Specify the location of the collection enginedirectory for the appropriate target operating system.

v Modify the discovery profile for the Host storage sensor on the TADDMserver. Type the path to the collection engine directory in theCollectionEnginePath or the CollectionEngineWindowsPath attribute or both, ifrequired.

4. Modify the discovery profile for the Host storage sensor on the TADDM server.Set the deployCollectionEngine attribute value to false.

5. Verify that correct user permissions are granted.The commands that are used by the Host storage sensor carrying out thediscovery can require privilege escalation. Typically, this escalation is done bysetting the file access permissions using the setuid (set-user-ID mode bit) termor by using the sudo command. For Windows operating systems, the discoveryuser must be a member of the Administrators group.

Configuring the discovery profileThe Host storage sensor, is not enabled by default. To enable the sensor, you mustcreate a discovery profile and then enable the sensor from the new profile.

The collection engine uses the HBA (host bus adapter) API, to discover the HBAsand FC volumes that are configured on the host system. For a successful discovery,the vendor's HBA API library must be installed and configured correctly on thehost system.


The following attributes can be modified:

deployCollectionEngineThe default value for the deployCollectionEngine attribute is true. Thesensor copies the collection engine file to a location on the target hostsystem. After the discovery is complete the collection engine file is deletedfrom the host. The location is entered in the collectionEnginePath or thecollectionEngineWindowsPath attribute. If no path is specified onWindows systems, the collection engine file is copied to the TEMP directory.For all other systems, the collection engine file is copied to the homedirectory of the user (running the discovery) on the target host system.

If the value is false the collection engine file is not copied.

collectionEnginePathThere is no default value for the collectionEnginePath attribute. Enter theabsolute path to the UNIX collection engine directory, if required.

collectionEngineWindowsPathThere is no default value for the collectionEngineWindowsPath attribute.Enter the absolute path to the Windows collection engine directory, ifrequired.

Entering the Windows path when the directory resides on a network drive(created using the net use command), might not work. Instead, enter theWindows path using the UNC (Universal Naming Convention) method.For example, \\hostname\share\CollectionEngine.

collectionEngineSudoCommandThere is no default value for the collectionEngineSudoCommand attribute.Enter the command to use for privilege escalation on UNIX systems.

collectionEngineTimeoutThe default value for the collectionEngineTimeout attribute is 30. Thisvalue specifies the time interval in minutes before a timeout occurs duringa discovery.

collectionEngineForceUniqueNameThe default value for the collectionEngineForceUniqueName attribute isfalse. If the value is false, the collection engine is not renamed when thecollection engine is copied to the target system. If the value is true, a timestamp is added to the name of the collection engine before it is copied tothe target system.

If you want to use sudo to give the discovery user permission to run thecollection engine, then the collection engine name cannot be changed. Inthis case, the default value of false must be used.

In environments that use concurrent discovery, if multiple discoveries areperformed at the same time, against the same target systems, collisions canoccur when deploying the collection engine. In situations like this, thecollectionEngineForceUniqueName attribute can be set to true to force thename of the collection engine to be unique on the target system. If thisattribute is set to true, sudo cannot be used.

If the Host storage sensor is enabled, do not enable the Storage sensor. If bothsensors are enabled, some of the storages resources are discovered twice.





Typically, an account with non-root privilege can be used. The commands that areused by the Host storage sensor carrying out the discovery can require privilegeescalation. Typically, this escalation is done by setting the file access permissionsusing the setuid (set-user-ID mode bit) term or by using the sudo command.


The sensor uses the following entries, which explicitly specify the location of thecollection engine directory, in the collation.properties file:

com.collation.discover.agent.path.Linux

com.collation.discover.agent.path.SunOS

com.collation.discover.agent.path.HP-UX

com.collation.discover.agent.path.AIX

com.collation.discover.agent.path.Vmnix

You can specify each of these properties as a scoped property by appending an IPaddress or a scope set name to the property, for examplecom.collation.discover.agent.path.Linux.1.2.3.4.

If the collection engine exits on multiple target computers that have the sameoperating system, but the collection engines reside in different paths, enter thepaths in the collation.properties file. Separate each unique path with a colon.

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

Commands fail because of insufficient privileges

ProblemCommand failures occurred due to permissions denied errors and arerecorded in the log files.

SolutionVerify that the commands that require privilege escalation are configuredcorrectly.

Dscovery takes a long time to run

ProblemThe discovery takes a long time to run.

SolutionCheck if the StorageSensor sensor is enabled and disable it. If both sensorsare enabled, some of the storages resources are discovered twice.


Host storage data is not discovered

ProblemHost storage data is not discovered.

SolutionVerify that the vendor's host bus adapter (HBA) API library files areinstalled and configured correctly on the host system. Missing library filesmight be identified in the HostStorageSensor log file.

WWPN and WWNN information are not displayed

ProblemThe worldwide port name (WWPN) and worldwide node name (WWNN)for an FC volume are not displayed.

SolutionTADDM uses the HBA API for FC volume discovery. The HBA APIprovides, a mapping from the OS identification of a SCSI volume to the FCrepresentation of the volume. The FC representation includes the WWPNof the port from the HBA that finds the volume. On multiport HBAs, thereis no way to determine which port a SCSI volume applies to. Thislimitation is in the HBA API. The HBA API specification has been updatedto address this issue, but the change might not be implemented in all HBAAPI libraries. Ensure that the latest version of the HBA vendor's HBA APIlibrary is installed on the target host system. In summary, if the HBA APIis unable to provide the mapping of a SCSI volume to its FCrepresentation, then the WWPN and WWNN cannot be determined.

Expected number of HBAs are not displayed

ProblemTADDM does not display the expected number of HBAs.

SolutionTADDM uses the HBA API for HBA discovery. For each adapter that theHBA API returns, TADDM creates an HBA model object. The adaptersWWNN is used by TADDM to name the HBA. The number of adaptersmight not match the number of physical HBA cards that are installed inthe host computer system, or the number of WWNNs returned by thebasic system commands.

How the HBA API library interprets adapters and WWNNs are determinedby the HBA vendor's, HBA API library implementation. For example, somevendors might represent a multiport HBA card using one adapter with oneWWNN. Other vendors can represent a multiport HBA card using oneadapter per port, with each adapter having its own unique WWNN.

Port type and port speed are not displayed

ProblemThe port type and port speed for an FC port are not displayed.

SolutionTADDM uses the HBA API for FC Port discovery. However, some HBAAPI libraries might not support these attributes, or the HBA vendor's HBAAPI library might need to be updated. Ensure that the latest version of theHBA API library is installed on the target host system. If the HBA APIlibrary cannot determine the port type and port speed, then theseattributes are not displayed.


SCSI bus, SCSI target and SCSI LUN are not displayed correctly

ProblemThe SCSI bus, SCSI target, and SCSI LUN for an FC volume are notdisplayed or the correct values are not displayed.

SolutionTADDM uses the HBA API to discover SCSI information about an FCvolume. However, some HBA API libraries might not support theseattributes, or might not return the correct values for these attributes. Toresolve this problem, the HBA vendor's HBA API library might need to beupdated. Ensure that the latest version of the HBA API library is installedon the target host system. If the HBA API library cannot determine theSCSI information, then these attributes are not displayed or might displayincorrect values.

FC volume information is not displayed correctly

ProblemThe FC volume information is not displayed or does not display correctvalues.

SolutionTADDM uses the HBA API to discover information about an FC volume.However, if there is a problem with the HBA API library, TADDM mightdisplay incorrect values for some FC volume attributes. For example, blocksize. To resolve this problem, ensure that the latest version of the HBA APIlibrary is installed on the target host system and configured correctly. If theHBA API library is not configured correctly, FC volume attributes mightnot display or might display incorrect values.

IBM Tivoli Storage Productivity Center sensorThe IBM Tivoli Storage Productivity Center sensor discovers storage resources thatare related to a storage area network (SAN) and Network Attached Storage (NAS).The sensor extracts data from a Tivoli Storage Productivity Center database.

The following resources are examples of what the sensor discovers:v Storage arraysv Switchesv Hostsv Fabricsv Zonesv Storage volumesv Array and switch portsv File systemsv Disk partitionsv NAS-related data

Some of these resources can also be discovered by the host storage sensor (forexample, data that is related to hosts) and the Fibre Channel switch sensor (forexample, data that is related to switches).



TPCStorageSensor

Model objects with associated attributesThe IBM Tivoli Storage Productivity Center sensor creates model objects withassociated attributes. The attributes indicate the type of information that the sensorcollects about storage resources that are stored in Tivoli Storage ProductivityCenter database.


dev.BasedOnExtent

v Sourcev Targetv Type

dev.Controller

v Namev Parent

dev.DiskDrive

v DiskSizev Modelv Namev Parentv SerialNumberv Typev Vendor

dev.DiskPartition

v Capacityv Namev Parentv PartitionTypev RealizedBy

dev.FCPort

v Labelv Parentv PermanentAddressv PortNumberv PortTypev Speed

dev.FCVolume

v Capacityv FCPLunv Namev Parent


v Typev PortWWNv HostPathsv BasedOn

dev.RealizesExtent


dev.SCSIPath

v ArrayVolumev HostEndPointv LUNv Parentv Volume


v WorldWideName

dev.TapeDrive

v Labelv Typev WorldWideName

net.IpAddress

v DotNotationv StringNotation

net.IpInterface

v IpAddressv Parent

relation.ConnectedTo


storage.Fabric

v Fcswitchv Labelv Namev SourceTokenv Virtualv ZoneSetsv Zones

storage.FCSwitch

v FCPortsv FCSwitchStatusv Fcportv ManagementURL


v Manufacturerv Modelv Namev ROMVersionv SerialNumberv Typev WorldWideNamev IpInterfaces

storage.StoragePool

v AnsiT10Idv Capacityv Labelv Membersv Raid Levelv RemainingManagedSpacev StorageSubSystemv TotalAvailableSpacev TotalManagedSpace

storage.StorageSubSystem

v AllocatedCapacityv AnsiT10Idv AvailabilityStatev AvailableCapacityv CacheSizev FCPortsv Fqdnv IpInterfacesv IsNetworkAttachedv Manufacturerv Membersv MemorySizev Modelv NumCPUsv ROMVersionv SerialNumberv StoragePoolsv Typev VolumeGroupCapacityv VolumeGroupFreeSpace

storage.StorageVolume

v BlockSizev Capacityv FreeSpacev Name


v Parentv RealizedByv RedundancyMethodv SourceTokenv Typev Virtualv Paths

storage.TapeLibrary

v AnsiT10Idv Descriptionv Devicesv Manufacturerv Modelv ROMVersionv SerialNumberv TapeMediaChangersv Type

storage.TapeMediaChanger

v Captionv Descriptionv Fqdnv Labelv ROMVersionv Typev WorldWideName

storage.Zone

v Activev Descriptionv Namev Parent

storage.ZoneSet

v Activev Labelv Namev Parentv Zones

Multiple operating systems:

sys.aix.Aixsys.hpux.HpUxsys.linux.Linuxsys.netware.Netwaresys.OperatingSystemsys.sun.Solarissys.vmware.VmwareESX


sys.windows.WindowsOperatingSystem

The following attributes are associated with these model objects:v FQDNv OSConfidencev OSNamev OSVersionv Parentv SoftwareComponentsv SystemGuid

Multiple Computer Environments:

sys.aix.AixUnitaryComputerSystemsys.ComputerSystemsys.hpux.HpUxUnitaryComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.SunSPARCUnitaryComputerSystemsys.vmware.VmwareUnitaryComputerSystemsys.windows.WindowsComputerSystem

The following attributes are associated with these model objects:v CPUSpeedv CPUTypev Devicesv FCPortsv FileSystemsv Fqdnv IpInterfacesv Manufacturerv MemorySizev Modelv NumCPUsv OSInstalledv OSRunningv SerialNumberv Signaturev Typev Namev UUIDv MacAddressv VMID

sys.FileSystemExport

v Namev Parent

sys.FileSystemService

v Exportsv Host


v Name

sys.NFSExport

v Namev Parent

sys.NFSService

v Exportsv Hostv Name

Multiple file systems:

sys.LocalFileSystemsys.sun.SolarisFileSystemsys.unix.UnixFileSystemsys.windows.WindowsFileSystem

The following attributes are associated with these model objects:v AvailableInodesv AvailableSpacev Capacityv MountPointv Parentv StorageExtentv TotalInodesv Type

sys.SMBExport

v Namev Parentv Pathv Type

sys.SMBService

v Exportsv Hostv Name

sys.SoftwareComponent

v Namev Parentv SoftwareVersion


Configuring the Tivoli Storage Productivity Center properties fileThe Tivoli® Storage Productivity Center sensor uses SQL queries to extract datafrom the Tivoli Storage Productivity Center database. The SQL queries are definedin the tpc.config file and the execution of these queries is controlled by theproperties defined in tpc.properties file.


The tpc.config and the tpc.properties are located in: COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.srm.tpc_7.2.0.

The sensor uses the following entries in the tpc.properties file to determinewhich queries to run:

com.ibm.cdb.discover.sensor.app.srm.tpc.ArrayQueriesThis property is related to array resources. By default, the followingqueries are enabled: ARRAY, ARRAY_SUM_SOURCE, ARRAY_VOLUME_GROUP,ARRAY_DRIVE, ARRAY_PORT, ARRAY_VOLUME.

com.ibm.cdb.discover.sensor.app.srm.tpc.HostQueriesThis property is related to host resources. By default, the following queriesare enabled: HOST, HOST_PORT, HOST_DEVICE_GROUP, HOST_DEVICE,HOST_DEVICE_PARTITION, HOST_DEVICE_PARTITION_DEVICE, HOST_FS,HOST_FS_EXPORT, HOST_AGENT, HOST_SCSI_PATH.

The HOST_SCSI_PATH query is used to create the end-to-end storagemapping from Fibre Channel volumes on a host to the volumes on astorage array. This query is enabled by default. Depending on how largethe storage environment is, running this query can increase the discoverytime of the sensor significantly. Hence, when discovering large storageenvironments, it is better to enable the HOST_SCSI_PATH query onlyoccasionally. To disable this query, do not include the HOST_SCSI_PATH inthe property: com.ibm.cdb.discover.sensor.app.srm.tpc.HostQueries.

The following example shows thecom.ibm.cdb.discover.sensor.app.srm.tpc.HostQueries property with theHOST_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.FabricQueriesThis property is related to fabric resources. By default, the followingqueries are enabled: FABRIC, ZONE_SET, ZONE.

com.ibm.cdb.discover.sensor.app.srm.tpc.SwitchQueriesThis property is related to switch resources. By default, the followingqueries are enabled: SWITCH, SWITCH_PORT.

com.ibm.cdb.discover.sensor.app.srm.tpc.NASQueriesThis property is related to NAS resources. By default, the following queriesare enabled: NAS_FILER, NAS_CONTROLLER, NAS_VOLUME, NAS_FS,NAS_DEVICE, NAS_FS_EXPORT.

com.ibm.cdb.discover.sensor.app.srm.tpc.TapeQueriesThis property is related to TAPE resources. By default, the followingqueries are enabled: TAPE_LIBRARY, TAPE_MEDIA_CHANGER, TAPE_DRIVE.

com.ibm.cdb.discover.sensor.app.srm.tpc.SummaryQueriesThis property is related to SUMMARY resources. By default, the followingquery is enabled: PORT_CONNECTIVITY.

The following properties are used to control the discovery of certain types ofcomputer systems by the IBM® Tivoli® Storage Productivity Center sensor:

com.ibm.cdb.discover.sensor.app.srm.tpc.ignoreAixCompSys=trueThis property determines whether the IBM® Tivoli® Storage ProductivityCenter sensor discovers computer systems on AIX operating systems or


not. By default, it is set to true which means that the sensor does notdiscover computer systems on AIX operating systems.

com.ibm.cdb.discover.sensor.app.srm.tpc.IgnoreCSWithoutMacaddr=trueThis property determines whether the IBM® Tivoli® Storage ProductivityCenter sensor discovers computer systems without a MAC address. Bydefault, it is set to true which means that the sensor does not discovercomputer systems without a MAC address.

Configuring the discovery profileThe TPCStorageSensor is enabled by default in the discovery profile.

Create a new profile to modify the following attributes:

discoverHostsThe default value for the discoverHosts attribute is true. The sensordiscovers host-related data, for example, ComputerSystem, disks, FC ports,FC volumes, storage volumes, disk partitions, local file systems, and filesystem services.

If the value is false, host-related data is not discovered by the sensor.

discoverSwitchThe default value for the discoverSwitch attribute is true. The sensordiscovers switch related data, for example, switch, switch ports, and FCports.

If the value is false, switch related data is not discovered by the sensor.

restrictByScopeThe default value for the restrictByScope attribute is false. The sensordiscovers all the hosts that the Tivoli Storage Productivity Center serverhas already discovered.

If the value is true, the sensor discovers the hosts within the discoveryscope range of the sensor.

The Host storage sensor and the Fibre Channel switch sensor also discover datarelated to hosts and switches. When discoverHosts and discoverSwitch areenabled, consider disabling the Host storage sensor and the Fibre Channel switchsensor to prevent resources being discovered twice.



use for authentication to the Tivoli Storage Productivity Center server.3. Select Database as the Component Type and DB2 as the Vendor.4. Specify the access information (user name and password) that TADDM must

use for authentication to the Tivoli Storage Productivity Center database.

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


Problems connecting to the Tivoli Storage Productivity Centerdatabase cause sensor failure

ProblemThe sensor fails due to problems connecting to the Tivoli StorageProductivity Center database.

SolutionVerify that the DB2 credentials of the Tivoli Storage Productivity Centerdatabase have been entered.

Host computers are not discovered

ProblemHost computers are not discovered.

SolutionThe sensor only discovers host systems that are managed by the TivoliStorage Productivity Center agent. In addition, verify that the attributediscoverHosts is true for the sensor.

Discovery takes a long time to run

ProblemThe discovery takes a long time to run.

SolutionIf the attribute discoverHosts is true, check if the HostStorageSensorsensor is enabled and disable it. If both sensors are enabled, some of thestorages resources are discovered twice.

If the attribute discoverSwitch is true, check if the FCSwitchSensor sensoris enabled and disable it. If both sensors are enabled, some of the storagesresources are discovered twice.

This problem can also happen if some of the queries that are enabled,generate a large volume of data. For example, some of the queries that cangenerate large volumes of data are: ARRAY_VOLUME, HOST_SCSI_PATH,and SWITCH_PORT. By default, these queries are disabled.

Computer systems are not reconciled

ProblemComputer systems discovered by the TPCStorageSensor do not reconcilewith the same computer systems discovered by the computer systemsensors.

Solution

Computer systems in a storage environment can be physically partitionedor virtualized. If these systems are discovered by the TPCStorageSensor,and also by a computer system sensor, the two sets of discovered resourcesare not reconciled with each other. For example:v Logical partitions (LPARs) on pSystems discovered by TPCStorageSensor

and AixComputerSystemSensorv Virtual I/O Server (VIOS) discovered by TPCStorageSensor and HMC

sensorv Node partitions (NPARs) on HP systems discovered by

TPCStorageSensor and HpUxComputerSystemSensor


v Zones on Solaris systems discovered by TPCStorageSensor andSunSparcComputerSystemSensor

To ensure that there is no duplication of computer systems, in the TADDMUI you must select the duplicate computer systems and merge themmanually.

Out-of-memory error when HOST_SCSI_PATH query is enabled

ProblemDepending on the storage environment, the HOST_SCSI_PATH query canreturn a large result set which might lead to an out-of-memory error.

SolutionThe sensor caps the number of rows it processes for the HOST_SCSI_PATHquery to a default value of 20,000 in order to prevent out-of-memoryerrors. The value is based on:v Default heap size of the discover JVM (which is 1024 MB)v Default agent timeout value (which is 600000 ms)

In addition, you can configure the sensor to prevent out-of-memorymessages, when the HOST_SCSI_PATH query is enabled by using one ofthe following methods:

Modify the default number of rows processed by the sensorEdit the COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.srm.tpc_7.2.0/tpc.propertiesfile and add the following property:com.ibm.cdb.discover.sensor.app.srm.tpc.HOST_SCSI_PATH.maxrows= X

where X is the maximum number of rows the sensor processes forthis query.

If this value is greater than 20,000:v Increase the heap size allocated for the Discover JVM. Edit the

$COLLATION_HOME/etc/collation.properties and change thecom.collation.Discover.jvmargs.ibm property.For example, to set the heap size to 1824 MB, add the followingline:com.collation.Discover.jvmargs.ibm=-Xdisableexplicitgc -Xmx1824m

v Increase the agent timeout for the Discover JVM. In the$COLLATION_HOME/etc/collation.properties file, add thefollowing property, where value is the number of millisecondsallowed for the sensor to run:com.collation.discover.agent.TPCStorageSensor.timeout=value

If you do not specify a value, the default value of 600000 isused.

v Restart TADDM.

Restrict the scope of storage arrays and Computer systems discoveredThe number of rows returned by the HOST_SCSI_PATH query canbe reduced by restricting the scope of the arrays and computersystems discovered.1. From the Discovery Management Console, click the Scope

icon. Select the Scope Set that contains the Tivoli StorageProductivity Center server to be discovered. Include the IP


address, Range, or Subnet information of the arrays andcomputers system to be discovered. The IP address of thestorage arrays and IP address of the computer system must bein the same scope set as the Tivoli Storage Productivity Centerserver for the discovery. These values enable the SCSI pathdata to be included in the results of the discovery.

2. From the Discovery Management Console, click the DiscoveryProfiles icon.

3. In the Discovery Profiles window, click New.4. In the Create New Profile window, type the profile name and

description. In the Clone existing profile field, click Level 3Discovery , and click OK.

5. In the list of sensors, click TPCStorageSensor, and click New.6. In the Create Configuration window, type the name and

description for your configuration of the TPCStorageSensor,and select the Enable Configuration check box.

7. In the Configuration section of the Create Configurationwindow, to restrict the scope of discovery, clickrestrictByScope. Then double-click the Value field in the row,and type true.

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-IP-PORT.log(.N) to see the number of SCSI paths that exist perstorage array IP address and per host IP address. The followingtext is an example of the contents of the log file:SCSI PATH statistics by host ip address :ip#1/4 with ipAddress 10.3.41.230 has 160 valid scsi pathsip#2/4 with ipAddress 10.3.41.289 has 527 valid scsi pathsip#3/4 with ipAddress 10.3.43.19 has 108 valid scsi pathsip#4/4 with ipAddress 10.3.42.211 has 160 valid scsi paths

SCSI PATH statistics by array ip address:ip#1/2 with ipAddress 10.0.15.201 has 693 valid scsi pathsip#2/2 with ipAddress 10.0.17.2 has 736 valid scsi paths

Run a discovery with the Tivoli Storage Productivity Center server in ascope of its own

To get the complete result set of the HOST_SCSI_PATH query andprevent 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.


Storage sensorThe storage sensor discovers the storage that is attached to a computer system.

The following resources are examples of what the sensor discovers:v Disksv Partitionsv Logical volumesv Physical volumesv File systems


StorageSensor

Limitations

Access to the /dev/dsk directory is not available on Solaris local or branded zonetarget systems. Therefore, not all storage information is retrieved.


The sensor creates the following model objects:v dev.BasedOnExtentv dev.ControlledByv dev.Controllerv dev.DiskDrivev dev.DiskPartitionv dev.FCVolumev dev.RealizesExtentv dev.SCSIVolumev dev.StorageExtentv dev.StorageVolumev sys.NFSFileSystemv sys.unix.UnixFileSystemv sys.LocalFileSystem







For more information, see the topic “Commands that might require elevatedprivilege” in the “Administering” topics in the TADDM information center.


The following TADDM server properties specify operating system commands thatTADDM uses to retrieve storage information:v com.collation.platform.os.command.lvm.lvdisplayv com.collation.platform.os.command.lvm.vgdisplayv com.collation.platform.os.command.lvm.pvdisplayv com.collation.platform.os.command.lputil.SunOS

These commands require elevated privilege to run on the target system, and theymust be configured to use the sudo command.

For more information, see the topic “Commands that might require elevatedprivilege” in the “Administering” topics in the TADDM information center.

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

General problems

Determine whether information is missing, and identify any command failures dueto permissions denied errors. Verify that commands that require privilegeescalation are properly configured. See Configuring the collation.properties fileentries for details.

Veritas Storage Foundation sensorThe Veritas Storage Foundation sensor discovers Veritas Storage Foundationsystems.

The Veritas Storage Foundation sensor combines the following principalcomponents and provides a solution for online storage management:v VERITAS Volume Managerv VERITAS File System

Physical disks are grouped into logical volumes to improve disk utilization andreduce wasted space. VERITAS Volume Manager allows administrators to workwith logical names (volumes) rather than through direct access to physical devices.

The VERITAS File System also provides an enterprise journaling file systemincreasing performance and reliability.

The Veritas Storage Foundation sensor is responsible for discovering the followinggeneral Volume Manager configurations:v Version


v Installation directoryv Objects under the control of VxVM (for example, Volumes and Disk Groups) and

relationships between them.

The second component, VERITAS File System, is recognized as a local file systemand the disk layout version is collected.


VeritasStorageSensor

Security issues

The default user to discover Computer System is used.

Limitations

The licenses are not supported. There are no application descriptors.


The sensor creates the following model objects:v app.ConfigFilev app.SoftwareInstallationv dev.MediaAccessDevicev dev.veritas.VeritasDiskGroupv dev.veritas.VeritasPlexv dev.veritas.VeritasSubdiskv dev.veritas.VeritasVMDiskv dev.veritas.VeritasVolumev sys.LocalFileSystemv sys.veritasVeritasStorageService


The following properties may require elevated privilege.v com.collation.discover.agent.command.vxdisk=vxdisk

v com.collation.discover.agent.command.vxdg=vxdg

v com.collation.discover.agent.command.vxprint=vxprint

v com.collation.discover.agent.command.vxupgrade=vxupgrade

v com.collation.discover.agent.command.vxdf=df

Troubleshooting the sensorThis topic describes common problems that occur with the Veritas StorageFoundation sensor and presents solutions for those problems.


The sensor fails with a timeout error on a Windows platform

ProblemThe Veritas Storage Foundation sensor fails with a timeout error on aWindows platform

SolutionIn the configuration file, change the liteDiscoveryMode to true if thesensor times out on a Windows platform. The following example showsthe attributes within a predefined configuration file:<results xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<VeritasStorageAgentConfigurationxsi:type="coll:com.collation.platform.model.discovery.agent.

VeritasStorageAgentConfiguration"><enabled>true</enabled><familyName>DiscoverSensor</familyName><name>VeritasStorageSensor</name><seedClassName>com.collation.discover.seed.app.vsf.VeritasSFSeed

</seedClassName><agentClassName>com.collation.discover.agent.app.vsf.VeritasSFAgent

</agentClassName><liteDiscoveryMode>false</liteDiscoveryMode>

</VeritasStorageAgentConfiguration></results>


Notices

This information was developed for products and services offered in the U.S.A.IBM may not offer the products, services, or features discussed in this document inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not give youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.1623-14, Shimotsuruma, Yamato-shiKanagawa 242-8502 Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certaintransactions, therefore, this statement might not apply to you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct and use of those Web sites is at your own risk.


IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758 U.S.A.

Such information may be available, subject to appropriate terms and conditions,including in some cases payment of a fee.

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurement may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM's future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

If you are viewing this information in softcopy form, the photographs and colorillustrations might not be displayed.

TrademarksIBM, the IBM logo, and ibm.com® are trademarks or registered trademarks ofInternational Business Machines Corp., registered in many jurisdictions worldwide.Other product and service names might be trademarks of IBM or other companies.A current list of IBM trademarks is available on the Web at “Copyright andtrademark information” at http://www.ibm.com/legal/copytrade.shtml.


http://www.ibm.com/legal/copytrade.shtml

Itanium is a trademark or registered trademark of Intel Corporation or itssubsidiaries in the United States and other countries.

Java and all Java-based trademarks andlogos are trademarks or registeredtrademarks of Oracle and/or itsaffiliates.

Linux is a registered trademark of Linus Torvalds in the United States, othercountries, or both.

Microsoft and Windows are trademarks of Microsoft Corporation in the UnitedStates, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Other company, product, and service names may be trademarks or service marksof others.

Notices 295

��

Printed in USA

Cmdb Sensor PDF

Documents

Transcript of Cmdb Sensor PDF