Professional Documents
Culture Documents
Note Before using this information and the product it supports, read the information in Notices on page 293.
Edition notice This edition applies to version 7, release 2, modification 1 of IBM Tivoli Application Dependency Discovery Manager (product number 5724-N55) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright IBM Corporation 2008, 2012. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . vii Tables . . . . . . . . . . . . . . . ix About this information . . . . . . . . xi Chapter 1. Overview . . . . . . . . . 1
Sensors that are enabled by default . . . . . . Level 1 discovery profile . . . . . . . . Level 2 discovery profile . . . . . . . . Level 3 discovery profile . . . . . . . . Utilization discovery profile . . . . . . . Sensors that support asynchronous or script-based discovery . . . . . . . . . . . . . . Sensors that support discovery using IBM Tivoli Monitoring . . . . . . . . . . . . . . Sensor setup problems . . . . . . . . . . . . . . . 1 1 2 3 6 Asynchronous and script-based discovery support. . . . . . . . . . . . . . Configuring the sensor . . . . . . . . Using the WebSphere seed sensor for z/OS. . Troubleshooting the sensor . . . . . . . IBM WebSphere eXtreme Scale cache sensor . . Model objects with associated attributes . . . Configuring the sensor . . . . . . . . IBM WebSphere Message Broker sensor . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . IBM WebSphere MQ Server sensor . . . . . Asynchronous and script-based discovery support. . . . . . . . . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . iPlanet server sensor . . . . . . . . . . JBoss server sensor . . . . . . . . . . . Configuring the access list . . . . . . . Troubleshooting the sensor . . . . . . . LDAP sensor . . . . . . . . . . . . . Configuring the access list . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft Cluster sensor . . . . . . . . . Model objects with associated attributes . . . Configuring the access list . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft Exchange Server sensor . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft Exchange 2007 Server sensor . . . . Model objects with associated attributes . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft HyperV sensor . . . . . . . . . Model objects with associated attributes . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . Microsoft IIS Web server sensor . . . . . . Configuring the access list . . . . . . . Troubleshooting the sensor . . . . . . . NFS sensor . . . . . . . . . . . . . Oracle Application Server sensor . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . SAP CCMS server sensor . . . . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . SAP SLD server sensor . . . . . . . . . Configuring the sensor . . . . . . . . Troubleshooting the sensor . . . . . . . SMB server sensor. . . . . . . . . . . Troubleshooting the sensor . . . . . . . SMS server sensor . . . . . . . . . . . Configuring the collation.properties file entries SysImager sensor . . . . . . . . . . . . . . . . . . . . . . 47 48 54 58 64 65 65 65 66 67 67
. 7 . 7 . 9
iii
Configuring the sensor . . . . . . . Veritas cluster sensor . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . VMware Virtual Center server sensor . . . Model objects with associated attributes . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . WebLogic sensor . . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . WebLogic SSH sensor . . . . . . . . Resources that the sensor discovers . . . Asynchronous and script-based discovery support . . . . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
103 105 106 107 107 108 112 113 114 116 120 123 125
Troubleshooting the sensor . . . IP device sensor . . . . . . . IP interface sensor . . . . . . . Ping sensor . . . . . . . . . Configuring the collation.properties Troubleshooting the sensor . . . Port sensor . . . . . . . . . Session sensor . . . . . . . . Stack Scan sensor . . . . . . . Configuring the sensor . . . . Troubleshooting the sensor . . .
. . . . . . . . . . . . . . . . file entries . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . .
167 167 168 168 168 169 169 170 170 171 174
iv
LAN Manager SNMP sensor . . . Configuring the access list . . . NetFlow sensor. . . . . . . . Configuring the sensor . . . . NetScreen SNMP sensor . . . . . Configuring the access list . . . Nokia SNMP sensor . . . . . . Configuring the access list . . . PIX sensor . . . . . . . . . Configuring the access list . . . Configuring the collation.properties SNMP Light sensor . . . . . . Configuring the access list . . . SNMP MIB2 sensor . . . . . . Configuring the access list . . . Troubleshooting the sensor . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . file entries . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
207 207 208 209 211 212 212 213 213 214 214 215 215 216 218 219
221
. . . . . . . . . . . . . . . . . . . . . . . . . . 221 221 222 222 223 224 225 226 226 229 230 230 231 235 236 236 237 238 238 239 239 240 241 242 243 243
Solaris computer system sensor . . . . . Asynchronous and script-based discovery support . . . . . . . . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . Solaris zones generic sensor . . . . . . Sun Fire SysControl sensor . . . . . . . Model objects with associated attributes . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . Tru64 computer system sensor. . . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . VMware ESX computer system sensor . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . . Windows computer system sensor . . . . Configuring the sensor . . . . . . . Troubleshooting the sensor . . . . . .
. . . . . . . . . . . . . . . . . .
. 243 . . . . . . . . . . . . . . . . . 245 246 247 247 248 249 250 251 251 252 253 253 256 257 260 261 263
Notices . . . . . . . . . . . . . . 293
Trademarks . . . . . . . . . . . . . . 294
Contents
vi
Figures
1. 2. Calling sequence for SNMP Light sensor and SNMP MIB2 sensor . . . . . . . . . 180 Calling sequence for SNMP sensors, starting after the SNMP Light sensor or the SNMP MIB2 sensor is called . . . . . . . . . 180
vii
viii
Tables
1. 2. 3. 4. Sensors that are enabled by default 1 discovery . . . . . . . . Sensors that are enabled by default 2 discovery . . . . . . . . Sensors that are enabled by default 3 discovery . . . . . . . . Sensors that are enabled by default utilization discovery . . . . . for a . . for a . . for a . . for a . . Level . . . 1 Level . . . 2 Level . . . 3 . . . 6 5. 6. 7. 8. 9. 10. Sensors that support asynchronous or script-based discovery . . . . . . . . . 7 Sensors that support discovery using IBM Tivoli Monitoring . . . . . . . . . . . . . 8 Required WebLogic JAR files . . . . . . 116 Configuration parameters . . . . . . . 164 Foundry OID mapping example . . . . . 181 Level 2 bridge topology data . . . . . . 191
ix
xi
xii
Chapter 1. Overview
For each sensor, this reference includes overview information, and if applicable for the respective sensor, also includes configuration and troubleshooting information. For some sensors, information about the attributes that are associated with the model objects is also included. Where attributes are included, the attributes are available in the IBM Tivoli Common Data Model (CDM) but are not necessarily shown in the IBM Tivoli Application Dependency Discovery Manager (TADDM) UI.
Late-breaking updates
For late-breaking updates about TADDM 7.2.1 sensor support issues, see http://www.ibm.com/support/search.wss?q=taddm721relnotes.
IBM AIX computer system sensor on page AixComputerSystemSensor 225 Alteon port sensor on page 184 Alteon SNMP sensor on page 185 Alteon VLAN sensor on page 186 Anchor sensor on page 155 Asynchronous discovery sensor on page 156 BIG-IP port sensor on page 187 BIG-IP SNMP sensor on page 188 BIG-IP VLAN sensor on page 189 Bridge SNMP 2 sensor on page 192 Bridge SNMP sensor on page 190 Cisco Discovery Protocol sensor on page 196 Check Point SNMP sensor on page 194 Cisco IOS sensor on page 198 Cisco port sensor on page 199 Cisco VLAN sensor on page 200 Custom application server sensor on page 157 Custom MIB2 computer system sensor on page 158 Entity MIB sensor on page 202 Extreme VLAN sensor on page 203 Generic computer system sensor on page 158 Generic server sensor on page 159 IBM Hardware Management Console sensor on page 230 Host resources sensor on page 269 HP-UX computer system sensor on page 222 IBM i computer system sensor on page 237 IP device sensor on page 167 AlteonPortSensor AlteonSnmpSensor AlteonVlanSensor AnchorSensor ASDSensor BigIPPortSensor BigIPSnmpSensor BigIPVlanSensor BridgeSnmpSensor2 BridgeSnmpSensor CdpSensor CheckpointSnmpSensor CiscoIOSSensor CiscoPortSensor CiscoVlanSensor CustomAppServerSensor CustomMib2ComputerSystemSensor EntityMIBSensor ExtremeVlanSensor GenericComputerSystemSensor GenericServerSensor HmcSensor HostResourcesSensor HpUxComputerSystemSensor I5OSComputerSystemSensor IpDeviceSensor
Table 2. Sensors that are enabled by default for a Level 2 discovery (continued) Sensor Sensor name that is used in the UI and logs
IPSO computer system sensor on page 238 IPSOComputerSystemSensor IBM Integrated Virtualization Manager sensor on page 236 LAN Manager SNMP sensor on page 207 Linux computer system sensor on page 239 NetScreen SNMP sensor on page 211 Nokia SNMP sensor on page 212 OpenVMS computer system sensor on page 243 Ping sensor on page 168 Port sensor on page 169 Session sensor on page 170 SNMP MIB2 sensor on page 216 Solaris computer system sensor on page 243 Sun Fire SysControl sensor on page 248 Tru64 computer system sensor on page 251 VMware ESX computer system sensor on page 253 IvmSensor LanManagerSnmpSensor LinuxComputerSystemSensor NetscreenSnmpSensor NokiaSnmpSensor OpenVmsComputerSystemSensor PingSensor PortSensor SessionSensor SnmpMib2Sensor SunSparcComputerSystemSensor SysControlSensor Tru64ComputerSystemSensor VmwareComputerSystemSensor
Windows computer system sensor on page WindowsComputerSystemSensor 260 Solaris zones generic sensor on page 247 ZonesGenericSensor
IBM AIX computer system sensor on page AixComputerSystemSensor 225 Alteon port sensor on page 184 Alteon SNMP sensor on page 185 Alteon VLAN sensor on page 186 Anchor sensor on page 155 Apache sensor on page 12 AlteonPortSensor AlteonSnmpSensor AlteonVlanSensor AnchorSensor ApacheServerSensor
Chapter 1. Overview
Table 3. Sensors that are enabled by default for a Level 3 discovery (continued) Sensor Asynchronous discovery sensor on page 156 BIG-IP port sensor on page 187 BIG-IP SNMP sensor on page 188 BIG-IP VLAN sensor on page 189 Bridge SNMP 2 sensor on page 192 Bridge SNMP sensor on page 190 SAP CCMS server sensor on page 96 Cisco Discovery Protocol sensor on page 196 Check Point sensor on page 193 Check Point SNMP sensor on page 194 Cisco IOS sensor on page 198 Cisco port sensor on page 199 Cisco VLAN sensor on page 200 CiscoWorks sensor on page 201 Sensor name that is used in the UI and logs ASDSensor BigIPPortSensor BigIPSnmpSensor BigIPVlanSensor BridgeSnmpSensor2 BridgeSnmpSensor CCMSServerSensor CdpSensor CheckpointSensor CheckpointSnmpSensor CiscoIOSSensor CiscoPortSensor CiscoVlanSensor v CiscoWorks405FileUDS v CiscoWorks405UDS v CiscoWorksFileUDS v CiscoWorksSensor v CiscoWorksUDS Citrix server sensor on page 15 Custom application server sensor on page 157 Custom MIB2 computer system sensor on page 158 IBM DB2 sensor on page 131 CitrixServerSensor CustomAppServerSensor CustomMib2ComputerSystemSensor v Db2Sensor v Db2WindowsSensor DNS sensor on page 16 IBM Lotus Domino server sensor on page 27 DnsSensor v DominoDomainSensor v DominoServerDetailSensor v DominoInitialSensor Entity MIB sensor on page 202 Microsoft Exchange 2007 Server sensor on page 81 EntityMIBSensor Exchange2007Sensor
Microsoft Exchange Server sensor on page ExchangeServerSensor 77 Extreme VLAN sensor on page 203 Generic computer system sensor on page 158 Generic server sensor on page 159 IBM High-Availability Cluster Multi-Processing sensor on page 24 ExtremeVlanSensor GenericComputerSystemSensor GenericServerSensor HACMPSensor
Table 3. Sensors that are enabled by default for a Level 3 discovery (continued) Sensor IBM Hardware Management Console sensor on page 230 Host resources sensor on page 269 HP-UX computer system sensor on page 222 IBM i computer system sensor on page 237 Microsoft IIS Web server sensor on page 89 IBM Informix sensor on page 136 IP device sensor on page 167 iPlanet server sensor on page 71 Sensor name that is used in the UI and logs HmcSensor HostResourcesSensor HpUxComputerSystemSensor I5OSComputerSystemSensor IISWebServiceSensor Informix IpDeviceSensor IPlanetServerSensor
IPSO computer system sensor on page 238 IPSOComputerSystemSensor IBM Integrated Virtualization Manager sensor on page 236 JBoss server sensor on page 71 LAN Manager SNMP sensor on page 207 LDAP sensor on page 73 Linux computer system sensor on page 239 Microsoft HyperV sensor on page 87 IBM WebSphere MQ Server sensor on page 67 Microsoft Cluster sensor on page 74 NetScreen SNMP sensor on page 211 NFS sensor on page 91 Nokia SNMP sensor on page 212 OpenVMS computer system sensor on page 243 Oracle Application Server sensor on page 91 Oracle sensor on page 142 Ping sensor on page 168 PIX sensor on page 213 Port sensor on page 169 Session sensor on page 170 SAP SLD server sensor on page 99 SMB server sensor on page 101 SMS server sensor on page 102 SNMP MIB2 sensor on page 216 Microsoft SQL Server sensor on page 138 IvmSensor JBoss4xSensor LanManagerSnmpSensor LdapSensor LinuxComputerSystemSensor Microsoft HyperV Sensor MQServerSensor MSClusterSensor NetscreenSnmpSensor NFSServerSensor NokiaSnmpSensor OpenVmsComputerSystemSensor v OracleAppOpmnSensor v OracleAppSensor OracleSensor PingSensor PixSensor PortSensor SessionSensor SLDServerSensor SMBServerSensor SMSServerSensor SnmpMib2Sensor SqlServerSensor
Chapter 1. Overview
Table 3. Sensors that are enabled by default for a Level 3 discovery (continued) Sensor Storage sensor on page 288 Solaris computer system sensor on page 243 Sybase IQ sensor on page 152 Sybase sensor on page 147 Sun Fire SysControl sensor on page 248 IBM Tivoli Storage Productivity Center sensor on page 276 Tru64 computer system sensor on page 251 Veritas cluster sensor on page 105 Sensor name that is used in the UI and logs StorageSensor SunSparcComputerSystemSensor SybaseIQSensor SybaseSensor SysControlSensor TPCStorageSensor Tru64ComputerSystemSensor VeritasClusterSensor
Veritas Storage Foundation sensor on page VeritasStorageSensor 289 VMware Virtual Center server sensor on page 107 VMware ESX computer system sensor on page 253 WebLogic SSH sensor on page 123 VirtualCenterSensor VmwareComputerSystemSensor v WeblogicLauncherSensor v WeblogicApplicationSensor v WeblogicDomainSensor v WeblogicServerSensor IBM WebSphere sensor on page 45 v WebSphereCellSensor v WebSphereNodeSensor v WebSphereVersionSensor Windows computer system sensor on page WindowsComputerSystemSensor 260 Solaris zones generic sensor on page 247 ZonesGenericSensor
IBM AIX computer system sensor on page AixComputerSystemSensor 225 Apache sensor on page 12 IBM DB2 sensor on page 131 IBM Lotus Domino server sensor on page 27 Generic server sensor on page 159 Linux computer system sensor on page 239 IBM WebSphere MQ Server sensor on page 67 IBM Tivoli Utilization sensor on page 160 Oracle sensor on page 142 Solaris computer system sensor on page 243 WebLogic SSH sensor on page 123 IBM WebSphere sensor on page 45 ApacheServerSensor Db2Sensor DominoInitialSensor GenericServerSensor LinuxComputerSystemSensor MQServerSensor OperatingSystemUtilizationSensor OracleSensor SunSparcComputerSystemSensor WeblogicLauncherSensor WebSphereVersionSensor
Chapter 1. Overview
Monitoring session, without including the IBM Tivoli Monitoring Scope sensor in the Level 2 and Level 3 discovery profiles. Note: If your IBM Tivoli Monitoring managed computer systems are behind a firewall (are not reachable from TADDM discovery server), you might need to include the IBM Tivoli Monitoring Scope sensor in your profile with startSessionOnly option enabled. For details, see Configuring the discovery profile in IBM Tivoli Monitoring Scope sensor documentation. For Level 2 and Level 3 discovery of the systems that are monitored by IBM Tivoli Monitoring, the following features must be installed on the target system: v On Windows target systems, Microsoft .NET Framework must be installed. See the TADDM Administrator's Guide for information about configuring for discovery of Windows systems. v On Linux and UNIX target systems, uuencode and uudecode commands that are compliant with the Portable Operating System Interface (POSIX) must be installed. On Linux operating systems, these commands are typically included with the sharutils package. On AIX, Solaris, and HP-UX operating systems, these commands are installed by default. Not all sensors in a Level 2 or Level 3 discovery profile support discovery using Tivoli Monitoring. Table 6 lists the sensors that support discovery using Tivoli Monitoring. When a sensor runs within the Tivoli Monitoring session, it uses the Tivoli Monitoring access credentials rather than the access credentials that are configured for the sensor. The Tivoli Monitoring user account must have necessary authorization to access the application that is being discovered. For example, to discover IBM DB2 Universal Database (UDB) servers, the Tivoli Monitoring user account on the target DB2 server must be a member of the DB2 administration group.
Table 6. Sensors that support discovery using IBM Tivoli Monitoring Sensor Sensor name that is used in the UI and logs
IBM AIX computer system sensor on page AixComputerSystemSensor 225 Apache sensor on page 12 IBM DB2 sensor on page 131 Generic server sensor on page 159 Linux computer system sensor on page 239 IBM WebSphere MQ Server sensor on page 67 Storage sensor on page 288 Solaris computer system sensor on page 243 WebLogic SSH sensor on page 123 IBM WebSphere sensor on page 45 ApacheServerSensor Db2Sensor GenericServerSensor LinuxComputerSystemSensor MQServerSensor StorageSensor SunSparcComputerSystemSensor WeblogicLauncherSensor WebSphereVersionSensor
On Linux, Solaris, AIX, and Linux on System z operating systems, discovery never ends
Problem On a Linux, Solaris, AIX, or Linux on System z operating system, discovery never ends. Running the ps -ef command shows instances of the stop-local-anchor.sh process that remain for more than 5 minutes. Solution Access to the sudo command must be configured so that the TADDM user, which is the user that starts the TADDM server, can run sudo commands without having the password prompt displayed. To configure the sudo access in this way, complete the following steps: 1. Login to the TADDM server as the root user. 2. Enter the visudo command. 3. Type the following line in the /etc/sudoers file, where TADDM_USER is the user that starts the TADDM server:
<TADDM_USER> ALL=NOPASSWD:ALL
To verify that the sudo access is configured correctly, enter the following commands:
cd $COLLATION_HOME/bin sh ./stop-local-anchors.sh
If a password prompt opens, the NOPASSWD access has not been configured correctly for the TADDM user.
Chapter 1. Overview
A discovery of application servers that are running on the Solaris 10 operating system returns incorrect port numbers
Problem Incorrect port numbers are returned when you run a discovery of application servers that are running on the Solaris 10 operating system. Solution Ensure that lsof 4.77, or later, is installed on every system that is running on the Solaris 10 operating system. Versions of lsof prior to 4.77 do not support Solaris 10 6/06 or later. Additionally, there are two version of lsof 4.77. One is for the pre 6/06 Solaris 10 release, and the other is for the 6/06 Solaris 10 release, and later versions. Make sure that you install the version of lsof 4.77 that matches the version of the Solaris 10 Operating System that is installed.
10
Security issues
The sensor uses the command ntdsutil.exe during the discovery and this command requires elevated security privileges. To verify that the discovery account has adequate privileges, enter the following command on one line: On Windows 2000 and Windows Server 2003:
ntdsutil "domain management" connections "connect to server localhost" q "list" q q
v MaxReceiveBuffer v MaxResultSetSize v v v v
Copyright IBM Corp. 2008, 2012
11
v v v v
sys.ServiceAccessPoint v ContextIp v BindAddress v Name v ProductName v ProductVersion v VendorName sys.NamingContext v Index v Value
Apache sensor
The Apache sensor discovers Apache Web servers.
Prerequisites
The TADDM service account requires: v Execute permissions on the httpd binary file v Read access to the httpd.conf file
Limitations
The Apache sensor cannot discover the Apache server if the Apache server instance is configured or started in such a way that it rewrites its command line (for
12
example, rewrites the argv array), causing the Apache server instance to show in a process listing as httpd, without any path or command-line options.
Limitations
Some function that is provided by the Apache sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. Application descriptor discovery is not supported. The following attributes are not supported for a configuration file: v Last modified v Owner v Group v Permissions
Chapter 2. Application sensors
13
14
Security issues
The discovery user must have read permissions (defined in the Citrix Product console) for the Citrix configuration. To discover the Citrix Presentation Server configuration, you must have permission to query the Citrix WMI Provider. This provider must be running in order to be discovered. The Citrix WMI Provider is on your discovered system where the Citrix Presentation Server is installed. It is a part of the Citrix product. To grant this permission, complete the following steps: 1. 2. 3. 4. Log in to the Management Console for Metaframe Presentation Server. From the menu, select Actions > Permissions. Edit the user and group permissions. Ensure that the View farm management permission is granted. This permission is the minimal permission that must be granted to query the Citrix WMI provider. a. Select a user or group. b. Click Edit c. Select the appropriate permission: v View only: works for the Citrix sensor v Full administration: works for the Citrix sensor v Custom: the administrator can define their own access level
15
DNS sensor
The DNS sensor discovers Domain Name System (DNS) servers.
HIS sensor
The HIS sensor discovers a Microsoft Host Integration Server.
Prerequisites
Before you run this sensor, the following prerequisites must be met: v The discovery of the Windows Computer System must succeed. v The SNABase service must be running.
16
v Using the TADDM Windows Management Instrumentation (WMI) provider, WMI read access to the root/microsoftHis namespace must be granted. If the discovery of the Windows Computer System succeeded, this WMI read access is granted by default. Administrative-level access is preferable.
v ConfigServer v DisplayName v DisplayVerbConnection v DomainName v EventLogServerName v NetViewConnection v v v v PopupServerName RTMEndOfSession RTMOverflow RTMThreshold
17
v Services v TransportString v VendorName app.his.IPDLCService v BackupNetworkNameServers v CMDMaxRetry v CPName v DeviceDriver v DisplayName v v v v v v DllName IsRemotable LENNode LocalAddressAdapter LocalAddressIP MaxActivationAttempts
v MaxBTUReceive v MaxBTUSend v Name v Network v NodeID v Parent v PrimaryNetworkNameServer v ReceiveAckTimeout v ResolvedIP v UseDynamicPUDefinition app.his.APPCMode v v v v v AllowLZandRLE AutoActivate DisplayName EndPointOnly IsPriority
18
v v v v v v v v v v v v v v v v v v
AllowIncoming BlockId CompressionLevel DisplayName DynamicLuDef LUs LinkService Name NodeId Parent PartnerConnectionName PeerRole RemoteBlockId RemoteControlPoint RemoteEnd RemoteNetName RemoteNodeId RetryDelay
v RetryLimit v XIDFormat app.his.HISLUA v Compression v DisplayName v HighPriorityMode v Name v Number v Parent v Protocol v UserWksSecure app.his.HISLUDisplay v AssociatedLU v Compression v DisplayModel v v v v v v DisplayModelOverride DisplayName HISService Name Number Parent
19
v v v v v
v UserWksSecure app.his.PrintService v Account v ActivationRetryInterval v v v v v v ActivationRetryLimit AlwaysDoNL CanBePaused CanBeStopped DelayPrintStart Description
v DesktopInteract v DisplayName v DoAllFF v ErrorControl v ExitCode v FlushFinalFF v IgnoreCharsUnder3F v Name v NoEventLogOnSkippingTransparentSection v NoSpaceAfterFF v OperatingState v Parent v v v v v PathName Server ServiceName ServiceSpecificCode ServiceType
v SoftwareVersion v StartMode v Started v UseFixedTabs v UseProportionalFontChange app.his.SNAService v ControlPoint v v v v v HISConnections Name NetworkName Parent Server
20
Prerequisites
GenericComputerSystemSensor, along with prerequisite sensors, must be enabled in the discovery profile used for discovering the CSM cluster.
21
2. Set the following required attributes: masterServerNames The IP addresses or host names of CSM master nodes. This property must be set to start the CSM server sensor. 3. If appropriate, set the following parameters or accept the default values. lsNodeCommand The command used to determine CSM nodes. The default value is lsnode. nodeGrpCommand The command used to determine CSM nodes in the group. The default value is nodegrp. nodeGrpCommandDelimiter The delimiter between nodes in the nodeGrpCommand. The default value is ",". CFMDirectoryLocation The location of the CFM root directory. The default is /cfmroot. CFMDiscoveryMode The depth of file capture of the files and scripts in the CSM configuration directories. The valid values are as follows: v 0: No file information is captured. v 1: Only the file name and file information are captured. v 2: All file information and content is captured. The default value is 1. CFMDiscoveryPattern The file name pattern for files under the CFM root directory. The default value is "*". preRebootScriptsLocation The location of the scripts that are run before reboot. The default value is /csminstall/csm/scripts/installprereboot/. preRebootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ installprereboot/ directory. The default value is "*". postRebootScriptsLocation The location of the scripts that are run after reboot. The default value is /csminstall/csm/scripts/installpostreboot/. postRebootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ installpostreboot/ directory. The default value is "*". osUpgradePreRebootScriptsLocation The location of the scripts that are run after the OS is upgraded, but before reboot. The default value is /csminstall/csm/scripts/ osupgradeprerboot/. osUpgradePreRebootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ osupgradeprereboot/ directory.
22
The default value is "*". osUpgradePostRebootScriptsLocation The location of the scripts that are run after the OS is upgraded, and after reboot. The default value is /csminstall/csm/scripts/ osupgreadepostreboot/. osUpgradePostRebootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ osupgradepostreboot/ directory. The default value is "*". disklessBootScriptsLocation The location of the boot scripts for diskless nodes. The default value is /csminstall/csm/scripts/disklessboot/. disklessBootScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ disklessboot/ directory. The default value is "*". disklessPreBuildScriptsLocation The location of the pre-build scripts that are run for diskless nodes. The default value is /csminstall/csm/scripts/disklessprebuild/. disklessPreBuildScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ disklessprebuild/ directory. The default value is "*". dataScriptsLocation The location of any additional scripts or data files referenced by the scripts. The default value is /csminstall/csm/scripts/data/. dataScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ data/ directory. The default value is "*". updateScriptsLocation The location of the scripts that are run after any CSM updates have completed. The default value is /csminstall/csm/scripts/update/. updateScriptsDiscoveryPattern The file name pattern for files under the /csminstall/csm/scripts/ update/ directory. The default value is "*". nodesScope The scope of the IP addresses to which the CSM node sensors are restricted. doPingNodes Specifies whether ping sensors are run against discovered CSM nodes.
23
There are no specific sensor setup requirements associated with the CSMNodeSensor.
Prerequisites
The HACMP service and the cluster manager daemon must be running on the target computers.
Security issues
Privileges to execute the following commands on the discovered systems are required: lssrc, clstat, cltopinfo, clRGinfo, cllsserv, cllsif, cllsfs, clshowres, cllsgrp, get_local_nodename, cllssite.
Limitations
The following limitations apply: v TADDM supports only Apache servers that are running on the HACMP cluster. v Only one application server can run on the HACMP resource group.
24
HACMPCluster v ClusterID v ComputerSystems v ConnAuthMode v HeartbeatNetworks v v v v v v v MessageAuthMode MessageEncryption Nodes ResourceGroups State Substate UsePersistentLabel
HACMPClusterHeartbeatNetwork v Name v Netmask v NetworkElements v Parent v PrefixLength v Type HACMPClusterHeartbeatNetworkElement v L2Interface v v v v Name NetworkAddress Parent StorageVolume
v Type HACMPClusterManager v CurrentState v HacmpNode HACMPLocalAppResource v Node v Parent v StartScript v StopScript HACMPLocalResourceGroup v LocalState v Node v Parent HACMPNode v ClusterManager v LocalAppResources v LocalResourceGroups v Name v NetworkElements
Chapter 2. Application sensors
25
v v v v
HACMPResourceGroup v AppResources v FallbackPolicy v FalloverPolicy v FileSystems v v v v v v GlobalState LocalResourceGroups Nodes Parent PrimaryNode ServiceIpLabels
26
In the command output, check the version of the HACMP cluster, for example
local node vrmf is 0
Prerequisites
On the Lotus Domino system, a user account must be configured with the correct access to the resources being discovered. Ensure that the following requirements are met: v The Internet Inter-ORB Protocol (IIOP) server must be running on at least one Domino server for each Domino domain. v Add the IP address or the fully qualified domain name (FQDN) of the IIOP servers to the $COLLATION_HOME/osgi/plugins/ com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.2.0/
Chapter 2. Application sensors
27
plugin.xml file. You can append the port number of the Domino IIOP server to the server name. Adding the port number is optional. Typically, the default port number is 63148 for Domino Internet Inter-ORB Protocol (DIIOP). If anonymous access is required, the port number is 80 for HTTP. The following example illustrates how to add an IIOP server name:
<IIOPServers> <item> <name>example1-server.ibm.com[:Port_number]</name> <SSL>false</SSL> </item> <item> <name>example2-server.ibm.com[:Port_number]</name> <SSL>false</SSL> </item> </IIOPServers>
v For each of the IIOP servers, you must have a valid user ID and password. v The user ID on the IIOP server must have read permission to the names.nsf file. v You must specify a discovery scope containing all the server nodes, to obtain complete information about Domino clusters. v Check the server document in the Domino directory, and ensure that the user ID has access enabled for the security settings: Access Server Run restricted LotusScript/Java agents On the Lotus Domino system, a user account must be configured with the correct access to the resources being discovered, for example, files and databases. v For TADDM to connect to a Domino IIOP server using SSL, you must set the osgi/plugins/ com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.2.0/ plugin.xml file to true. Then, you must copy the TrustedCerts.class file to the $COLLATION_HOME/etc/domino_trusted directory on the TADDM server. The TrustedCerts.class file is located in the domino data folder/domino/java folder. v Issue the show task command in the Domino console to determine if the DIIOP task is running. v If the DIIOP task is not running, issue the load diiop command using the Domino console to load the DIIOP task. v Issue the tell diiop show config command to check the configuration. If you update the plugin.xml file, you must restart the TADDM server for the changes to take effect.
28
v v v v v v v v v v v v v v v v v v
app.lotus.DominoDomain app.lotus.DominoNamingContext app.lotus.DominoReplicas app.lotus.DominoSecurity app.lotus.DominoServer app.lotus.DominoTransactionLogging app.lotus.HTTPFilterSpecialtyServer app.lotus.IIOPConfig app.lotus.IMAPConfig app.lotus.InternetClusterManager app.lotus.LDAPConfig app.lotus.OtherDatabase app.lotus.POPConfig app.lotus.RemoteDebugManager app.lotus.SMTPConfig app.lotus.SpecialityServer app.lotus.WebConfig app.lotus.WebRetriever
Limitations
Most function that is provided by the Lotus Domino server sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. In an asynchronous or script-based discovery, only the Version attribute is supported. Application descriptor discovery is not supported.
29
The sensor does not start if the notes.ini file cannot be accessed
Problem For AIX operating systems, if the notes.ini file is not found in the processing environment the sensor does not start. Solution The user ID carrying out the discovery does not have access to the process environment due to security issues. Check the following entry in the collation.properties file:
com.collation.platform.os.command.psEnv.AIX
If required, add the sudo command to set the file access permissions.
30
Prerequisites
For a monitored computer system to be stored in the TADDM database, IBM Tivoli Monitoring must provide the computer system IP and MAC addresses in response to queries from the sensor.
Limitations
Discovery using the Tivoli Monitoring Scope sensor causes the following performance impacts in the Tivoli Monitoring environment: v An increase in CPU usage on the Tivoli Enterprise Portal Server and the Tivoli Enterprise Monitoring Server v An increase in network utilization v If two or more TADDM servers simultaneously perform discovery against one Tivoli Monitoring server, Tivoli Monitoring discovery is not successful. These performance impacts are present for the duration of the discovery and might also affect the performance of the Tivoli Monitoring functions, depending on the Tivoli Monitoring hardware that is used. The sensor does not discover hosts on a private network that uses network address translation (NAT).
31
32
Copying necessary files from the Tivoli Enterprise Portal Server to the TADDM server
You must copy some files from the Tivoli Enterprise Portal Server to the TADDM server. In a streaming server deployment, perform these steps on the discovery server, if you are configuring the sensor for the first time. You do not complete this procedure if you already copied the files from the Tivoli Enterprise Portal Server to the TADDM server and you upgraded to version 7.2.1 Fix Pack 1 or later. 1. On the TADDM server, verify that a $COLLATION_HOME/osgi/plugins/ com.ibm.cdb.session.itm_7.2.1.2/lib/itm directory exists. 2. Copy the following files from the Tivoli Enterprise Portal Server into the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.session.itm_7.2.1.2/lib/itm directory on the TADDM server: v browser.jar v v v v v cnp.jar cnp_vbjorball.jar kjrall.jar util.jar tap_cli.jar On Windows systems, copy the files from the ITM_INSTALLATION_DIR\CNB\ classes directory. On Linux and UNIX systems, copy the files from the ITM_INSTALLATION_DIR/ classes directory.
3. Copy the cfwk.zip from the Tivoli Enterprise Portal Server into the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.session.itm_7.2.1.2/lib/itm directory on the TADDM server. On Windows systems, copy the file from the ITM_INSTALLATION_DIR\GSK7\ classes directory. On Linux and UNIX systems, copy the file from the ITM_INSTALLATION_DIR/ ARCH/gs/classes directory. 4. On Linux and UNIX systems, use the following command to set the user and group of the previously copied files to the user and group that is used to run the TADDM server:
chown -R taddmuser:taddmuser $COLLATION_HOME/osgi/plugins/com.ibm.cdb.session.itm_7.2.1.2/lib/itm
33
bundle has a small footprint and is designed to be non-intrusive and used only during a TADDM discovery. If you are performing a Level 1 discovery, this task is not required. You must distribute the support bundle to the Windows discovery targets through the Tivoli Enterprise Monitoring Server depot. The support bundle must also be loaded into any remote Tivoli Enterprise Monitoring Server depots that exist in your Tivoli Monitoring environment. In addition to deploying the discovery target support bundle, you must ensure that each Tivoli Monitoring endpoint is configured for discovery. For example, each UNIX-based endpoint must have the LiSt Open Files (lsof) program installed. For more information, see the topic Configuring target computer systems in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center. On the TADDM DVD, the support bundle is in the KD7.zip or KD7_621.zip file in the /itm-discovery-support directory. Depending on the version of Tivoli Enterprise Monitoring Server, distribute the appropriate support bundle. For IBM Tivoli Monitoring Version 6.2.1-TIV-ITM-FP0001 or later, distribute the support bundle in KD7_621.zip. For IBM Tivoli Monitoring Version 6.2.2-TIV-ITM-FP0002 or later, distribute the support bundle in the KD7.zip. To distribute the support bundle to the discovery targets, complete the following steps: 1. Extract the appropriate support bundle file KD7.zip or KD7_621.zip file into a directory on the Tivoli Enterprise Monitoring Server. For example, the C:\TEMP directory on Windows and /tmp on Linux or UNIX system. 2. To add the support bundle to the Tivoli Enterprise Monitoring Server depot, run the tacmd command, as shown in the following sample. To suppress the confirmation, use the -f option. On Windows operating system:
C:\IBM\ITM\bin>tacmd login -u sysadmin -p mypassword -s localhost Validating user... KUIC00007I: User sysadmin logged into server on https://localhost:3102. C:\IBM\ITM\bin>tacmd addBundles -i C:\TEMP\KD7\072101000 KUICAB023I: Are you sure you want to add the following bundles to the C:\IBM\ITM\CMS\depot\ depot? Type : Product Code : Deployable : Version : Description : Host Type : Host Version : Prerequisites: Component d7 true 072101000 TADDM Discovery through ITM enablement WINNT WINNT
KUICAB024I: Enter Y for yes or N for no: y KUICAB020I: Adding bundles to the C:\IBM\ITM\CMS\depot\ depot. The time required to complete this operation depends on the number and size of the added bundles. KUICAB022I: The following bundles were successfully added to the C:\IBM\ITM\CMS
34
Type : Product Code : Deployable : Version : Description : Host Type : Host Version : Prerequisites:
Component d7 true 072101000 TADDM Discovery through ITM enablement WINNT WINNT
KUICAB024I: Enter Y for yes or N for no: y KUICAB020I: Adding bundles to the /opt/IBM/ITM/tables/TEMS/depot depot. The time required to complete this operation depends on the number and size of the added bundles. KUICAB022I: The following bundles were successfully added to the /opt/IBM/ITM/tables/TEMS/depot depot:
3. To obtain the managed system names for the Windows operating systems, use the tacmd listSystems -t NT command. For more information about the tacmd listSystems -t NT command, see tacmd CLI commands at: http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/ com.ibm.itm.doc_6.2.2fp2/tacmd.htm. 4. To distribute the support bundle from the Tivoli Enterprise Monitoring Server to the discovery targets, log in to the Tivoli Enterprise Monitoring Server, and run the tacmd command, as shown in the following sample: On Windows operating system:
C:\IBM\ITM\bin>tacmd login -u sysadmin -p mypassword -s localhost Validating user... KUIC00007I: User sysadmin logged into server on https://localhost:3102. C:\IBM\ITM\bin>tacmd addsystem -t d7 -n Primary:OMPDEV2:NT KUICAR010I: The agent type d7 is being deployed. KUICAR028I: The operation has been successfully queued for deployment, the transaction id is 121969167781300000018467, use the getDeployStatus CLI to view the status.
5. Check the status of deployment by entering the tacmd getDeployStatus command. For example:
C:\IBM\ITM\bin>tacmd getdeploystatus -g 121969167781300000018467 Transaction ID : 121969167781300000018467 Command : INSTALL Status : SUCCESS Retries : 0 TEMS Name : HUB_TEMS Target Hostname: Primary:OMPDEV2:NT Platform : WINNT Product : D7 Version : 072101000 Error Message : KDY0028I: Request completed successfully. Deployment request was processed successfully and is now completed.
35
These queries return the following information: v Version number of the agent on each endpoint v MAC address of each Linux endpoint v Operating system name and version of each endpoint To install the custom queries on the Tivoli Enterprise Monitoring Server, complete the following steps: Installing on Linux operating system: 1. Log in to the Tivoli Enterprise Portal Server, and copy the TEPS_Query.zip file to a local directory. In these instructions, the TEPS_Query.zip file is copied to the /tmp/teps directory and extracted. The install_zkd7.sql and uninstall_zkd7.sql files are then located in the /tmp/teps directory. 2. Install the custom queries:
/opt/IBM/ITM/bin/itmcmd execute cq "/opt/IBM/ITM/li6263/cq/bin/KfwSQLClient -d KFW_DSN f /tmp/teps/install_zkd7.sql"
Installing on Windows operating system: 1. Log in to the Tivoli Enterprise Portal Server, and copy the TEPS_Query.zip file to a local directory. In these instructions, the TEPS_Query.zip file is copied to the c:\TEMP\TEPS directory and extracted. The install_zkd7.sql and uninstall_zkd7.sql files are then located in the c:\TEMP\TEPS directory. 2. Change to the directory where the Tivoli Enterprise Portal Server is installed:
cd c:\IBM\ITM\CNPS
4. From the Tivoli Monitoring Services window, restart the Tivoli Enterprise Portal Server.
36
4. In the list of sensors, click ITMScopeSensor, and click New. 5. In the Create Configuration window, type the name and description for your configuration of the ITMScopeSensor, and select the Enable Configuration check box. 6. In the Configuration section of the Create Configuration window, to define a set of ports to look for the Tivoli Enterprise Portal Server, click portList. Then double-click the Value field in the row, and type each port number value, separating each value with a comma. 7. To configure the sensor not to use port 1920, click useDefaultPortList. Then double-click the Value field in the row, and type false. The default value for useDefaultPortList is true. If a port list is provided and useDefaultPortList is set to true, port 1920 is added to the list of ports to look for the Tivoli Enterprise Portal Server. 8. To create computer system objects that display in the discovered components tree during a discovery, click discoverITMEndpoints. Then double-click the Value field in the row, and type true. If you do not want to create computer system objects during a discovery, either do not type anything in the field, or type false. 9. Click OK to return to the Discovery Profiles window. 10. In the Discovery Profiles window, click Save.
Procedure
1. Make sure that the scope.properties file is created. 2. Include the sensor in your profile and set the startSessionOnly parameter to true in the configuration options.
Results
The sensor checks whether the IP address from the original scope is managed by ITM, and runs a session sensor. The sensor uses the ITM session only if it is allowed and preferred for the host. Restriction: The startSessionOnly parameter has a priority over all other configuration options. If enabled, the sensor does not start any other operations.
37
5. Type the credentials for the Tivoli Enterprise Portal Server. Use the credentials that are required to log in to the Tivoli Enterprise Portal Server rather than the credentials for the computer on which the Tivoli Enterprise Portal Server resides.
38
Uninstall on Windows operating system: 1. Log in to the Tivoli Enterprise Portal Server, and copy the TEPS_Query.zip file to a local directory. In these instructions, the TEPS_Query.zip file is copied to the c:\TEMP\TEPS directory and extracted. The uninstall_zkd7.sql file is then located in the c:\TEMP\TEPS directory. 2. Change to the directory where the Tivoli Enterprise Portal Server is installed:
cd c:\IBM\ITM\CNPS
4. From the Tivoli Monitoring Services window, restart the Tivoli Enterprise Portal Server.
3. To remove the support bundle from the Tivoli Enterprise Monitoring Server depot, run the tacmd command, as shown in the following sample. Provide the path to the directory where the installable bundles are located, using the -i option.
tacmd removeBundles -i C:\TEMP\KD7\062001000
Deleting the Tivoli Enterprise Portal Server files from the TADDM server
To uninstall the IBM Tivoli Monitoring Scope sensor configuration, you must delete the files that were copied from the Tivoli Enterprise Portal Server to the TADDM server. To delete the files copied from the Tivoli Enterprise Portal Server, complete the following steps: 1. On the TADDM server, delete the $COLLATION_HOME/osgi/plugins/ com.ibm.cdb.session.itm_7.2.1.1/lib/itm directory. 2. Restart the TADDM server.
39
Computer systems that are outside of the defined scope are created
Problem During a discovery, some computer systems that are outside of the defined scope are created. Solution If the discoverITMEndpoints attribute in the discovery profile for this sensor is set to true, the sensor, during a discovery, creates a computer system for each Tivoli Monitoring endpoint that is known to the Tivoli Enterprise Portal Server. This creation occurs even if an endpoint is outside of the initial discovery scope that included the portal server.
Updates made to the generated Tivoli Monitoring scope using the Discovery Management Console are overwritten
Problem Updates that have been made to the generated Tivoli Monitoring scope in the previous discovery using the Discovery Management Console are overwritten. Solution During a Level 1 discovery, a new scope is created based on the name of the Tivoli Enterprise Portal Server. This scope is overwritten the next time that the portal server is discovered during a Level 1 or Level 2 discovery. To change the generated Tivoli Monitoring scope, create a scope with a different name that contains the elements of the generated scope.
In a large Tivoli Monitoring environment, the sensor fails with a timeout error
Problem In a large Tivoli Monitoring environment, the Tivoli Monitoring Scope sensor fails with a timeout error. Solution In the etc/collation.properties file, edit the following property, where value is the number of milliseconds allowed for the sensor to run (for example, 60000 is 1 minute):
com.collation.discover.DefaultAgentTimeout=value
The sensor fails with a timeout error when slow network links or many router hops exist between the target systems and the Tivoli Enterprise Portal Server or TADDM
Problem The Tivoli Monitoring Scope sensor fails with a timeout error. Slow network links or many router hops exist between the target systems and the Tivoli Enterprise Portal Server or TADDM. The environment includes Windows, Linux, and UNIX systems. Solution This problem is caused by TCP buffer settings. Because the buffer sizes are sometimes too small, poor performance occurs with the TADDM sensors and the Tivoli Enterprise Portal Server.
40
To solve this problem, complete the following steps, depending on the operating system: On AIX systems: 1. Run the following commands:
/usr/sbin/no -o tcp_sendspace=32768 /usr/sbin/no -o tcp_recvspace=32768
2. Restart the TADDM server. On Linux systems: 1. Edit the /etc/sysctl.conf file with the following settings:
# increase TCP maximum buffer size net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # increase Linux autotuning TCP buffer limits # min, default, and maximum number of bytes to use net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216
2. Run sysctl -p to read in and set the new values. 3. Restart the TADDM server. On Solaris systems: 1. Run the following commands:
/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 32768 /usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 32768
Error message results from running the tacmd getDeployStatus command after deploying the discovery target support bundle
Problem One or more of the following messages result from running the tacmd getDeployStatus command after deploying the discovery target support bundle: v Error Message: KDY1024E: The command /opt/IBM/ITM/bin/CandleAgent
-h /opt/IBM/ITM start d7 did not start or stop agent. The command returned a return code. v Error Message: KDY1008E: The agent action INSTALL failed with a return code of for product code d7. The command /opt/IBM/ITM/tmaitm6/aix526/bin/kdy_xa -setCMS d7 produced the following error text: <Variable formatSpec="{4}">stdErr Text</Variable>. The specified return code was received from the two-way translator. v Error Message: KDY1024E: The agent failed to respond to the command C:\itmagent\installITM\Batch\kincli -startagent -akd7 did not start or stop agent. The command returned a failure return code.
Solution These messages do not indicate actual errors, because the discovery target support bundle is not intended to respond to the agent start or stop command. The Tivoli Monitoring cinfo command also does not list the support bundle, because the support bundle is an addition to the existing OS agent. Verify that the discovery target support bundle is correctly installed on the discovery target. From the Tivoli Monitoring directory on the target computer, run the directory command as shown in the following example:
Chapter 2. Application sensors
41
C:\Documents and Settings\Administrator>cd %CANDLEHOME% C:\IBM\ITM>dir taddm Volume in drive C has no label. Volume Serial Number is B81D-9114 Directory of C:\IBM\ITM\taddm 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 09/24/2010 06:38 PM <DIR> . 06:38 PM <DIR> .. 06:38 PM 6,656 Base64.exe 06:38 PM 1,960 KD7WINNT.dsc 06:38 PM 1,363 post.bat 06:38 PM 4,280 pre.bat 06:38 PM 249,856 TaddmTool.exe 06:38 PM 474,624 TaddmTool.pdb 06:38 PM 569,344 TaddmWmi.dll 06:38 PM 106,496 TaddmWmi.exe 06:38 PM 1,424 TaddmWmi.mof 06:38 PM 2,968,576 TaddmWmi.pdb 10 File(s) 4,384,579 bytes 2 Dir(s) 10,931,712,000 bytes free
The discovery support bundle files must be present in the %CANDLE_HOME%\taddm directory.
When running the sensor for a Level 2 discovery on Windows target systems, multiple command windows open on the computer where the Tivoli Enterprise Portal Server is running
Problem When you run the IBM Tivoli Monitoring Scope sensor for a Level 2 discovery on Windows target systems, multiple command windows open on the computer where the Tivoli Enterprise Portal Server is running. Solution The IBM Tivoli Monitoring Windows OS Agent is probably configured to run as a system service, and the option Allow Service to Interact with Desktop is enabled. Complete the following steps to correct this problem: 1. Right-click the agent in the Manage Tivoli Monitoring Services program. 2. Click Change Startup. 3. In the Log on As pane of the window that opens, clear the Allow Service to Interact with Desktop check box. 4. Click OK. 5. Again, right-click the agent in the Manage Tivoli Monitoring Services program. 6. Click Recycle.
42
Solution The administrator can remove these files manually at any time that discovery is not running. Removing these files during a discovery can cause discovery to fail.
v CTJTD3000E Starting - An error occurs and the sensor timed out Solution Verify that the Tivoli Enterprise Monitoring Server process on the Tivoli
Chapter 2. Application sensors
43
Monitoring server is running, and if necessary, restart the Tivoli Enterprise Monitoring Server. This process might shut down unexpectedly due to too many proxy requests, which is related to a known problem with Tivoli Monitoring 6.2.2. For more information, see Tivoli Monitoring APAR IZ52960.2.
Tivoli Monitoring scope does not include all endpoints defined on the Tivoli Enterprise Portal Server
Problem The Tivoli Monitoring scope created during a discovery does not include all the endpoints that are defined on the Tivoli Enterprise Portal Server. Solution Inactive endpoints and endpoints for which MAC addresses cannot be resolved are not included in a created scope set.
Targets are discovered by IBM Tivoli Monitoring session but not by SSH or WMI during a Level 2 discovery
Problem When an endpoint is discovered by the IBM Tivoli Monitoring Scope sensor, future Level 2 discoveries use Tivoli Monitoring for discovery by default. A direct connection (SSH or WMI) is not used. This method is used even if the IBM Tivoli Monitoring Scope sensor is not included in the discovery profile. Solution To discover the endpoint through SSH or WMI, define the following property in the collation.properties file: com.ibm.cdb.session.allow.ITM.endpoint_ip_address=false. See the TADDM Administrator's Guide for information about how to modify properties that affect how TADDM discovers Tivoli Monitoring endpoints.
Too many active report queries on the Tivoli Enterprise Portal Server
Problem The following informational message is generated in the SessionSensor.log file:
KFWITM460E: Too many active report queries from client IPAddress; exceeding limit at number requests.
Solution Increase the maximum number of pending requests. Edit the configuration settings on the Tivoli Enterprise Portal Server, on Windows operating systems edit the KFWENV file, and on Linux or UNIX operating systems edit the cq.ini file with the following settings:
KFW_REPORT_REQUEST_LIMIT_MAX=100 KFW_REPORT_REQUEST_LIMIT=30 KFW_REPORT_REQUEST_LIMIT_DURATION=300
The KFW_REPORT_REQUEST_LIMIT property specifies the normal limit of pending requests to the Tivoli Enterprise Portal Server from a single client. The KFW_REPORT_REQUEST_LIMIT_MAX specifies a temporary maximum limit of pending requests that can exceed the KFW_REPORT_REQUEST_LIMIT, only allowable during a burst of time defined by the KFW_REPORT_REQUEST_LIMIT_DURATION (in seconds).
44
Prerequisites
For IBM WebSphere Virtual Enterprise discoveries, you must install and run the IBM WebSphere Network Deployment Manager system and IBM WebSphere Virtual Enterprise. Also, at least one dynamic cluster must be defined. For IBM WebSphere JDBC driver discoveries, ensure that the following prerequisites are met: v Java is present in the system path variable. v The user has permission to execute Java. v The user has permission to read the JDBC driver JAR files. For IBM WebSphere JDBC driver discoveries on Oracle databases, you must also ensure that the user has permission to write to the directory containing the JDBC driver JAR files.
Limitations
The following limitations apply: v For discovery using IBM Tivoli Monitoring, TADDM supports only script-based discovery for the WebSphere sensor. v All active and inactive JDBC connections identified at server scope through JMX are resolved. JDBC connections scoped at cell, node, cluster, or application levels are not resolved. v JDBC connections that use native DB aliases configured in native DB clients are not supported. v Distributed WebSphere servers cannot be discovered on their own. The discovery is done from the dmgr (cell manager). To discover this machine, it must be in the discovery scope. If it is not in the discovery scope, the local-anchor log shows the following messages:
45
2008-05-17 11:52:54,375 [Thread: 0,8495] WARN j2ee.WebSphereAgent [WebSphereAgent.W.7] verifyStandaloneServer() determined cell to be distributed (DISTRIBUTED), terminating discovery 2008-05-17 11:52:54,379 [Thread: 0,8495] WARN j2ee.WebSphereAgent [WebSphereAgent.W.2] Terminating discovery of managed server/nodeagent portfolio_sptfde71-02_1 - discovery will be handled at cell level 2008-05-17 11:52:54,384 [Thread: 0,8495] DEBUG j2ee.WebSphereAgent discover() finalizing 2008-05-17 11:52:54,384 [Thread: 0,8495] DEBUG cdb.AnchorServer[0] server(0) sendMessage to:127.0.0.1:ReplyMsg:(#4):ip=null,host=localhost:MSG_SUCCESS:::result class:com.collation.discover.result.app.j2ee.WebSphereResult 2008-05-17 11:52:54,558 [Thread: 0,8495] DEBUG cdb.AnchorServer[0] server(0) readMessage:CloseMsg:(#160):ip=127.0.0.1,host=localhost: SERVER_HALT:SEND_STATS 2008-05-17 11:52:54,559 [Thread: 0,8495] DEBUG cdb.AnchorServer[0] server(0) sendMessage to:127.0.0.1:StatsMsg:(#5):ip=null,host=localhost:1 connections,0 classes,3/6 messages,1 agents 2008-05-17 11:52:54,568 [Thread: 0,8495] DEBUG cdb.AnchorServer[main] - halt: just told to halt 2008-05-17 11:52:54,568 [Thread: 0,8495] DEBUG cdb.AnchorServer[main] - doAbort: aborting all threads v The JVM runtime information that is the Java version and publisher name is discovered for each server that is running. The discovery of the runtime information is dependent on cell and node agent synchronization. Synchronization must be enabled for every node within a cell. The synchronization interval determines how up to date the discovery is. The most current information is gathered from the cell after the JVM information is propagated from the node agent. v When discovering a distributed WebSphere Application Server, the JDBC driver version is discovered only for JDBC providers that have a class path valid for the host running the deployment manager process. v The JDBC driver version for JDBC providers is not discovered for WebSphere Application Servers running on z/OS
46
v v v v v v v v v v v v v v v v v v
app.j2ee.websphere.WebSphereCluster app.j2ee.websphere.WebSphereConfiguredConnection app.j2ee.websphere.WebSphereConnector app.j2ee.websphere.WebSphereConnectorModule app.j2ee.websphere.WebSphereCustomUserRegistry app.j2ee.websphere.WebSphereDeploymentManager app.j2ee.websphere.WebSphereDynamicCache app.j2ee.websphere.WebSphereEFixInfo app.j2ee.websphere.WebSphereEJB app.j2ee.websphere.WebSphereEJBModule app.j2ee.websphere.WebSphereGlobalSecuritySettings app.j2ee.websphere.WebSphereJ2EEApplication app.j2ee.websphere.WebSphereJ2EEResource app.j2ee.websphere.WebSphereJ2EEResourceProperty app.j2ee.websphere.WebSphereJDBCConnectionPool app.j2ee.websphere.WebSphereJDBCDataSource app.j2ee.websphere.WebSphereJDBCProvider app.j2ee.websphere.WebSphereJMSDestination
v app.j2ee.websphere.WebSphereJMSProvider v app.j2ee.websphere.WebSphereJMSQueue v app.j2ee.websphere.WebSphereJMSTopic v v v v v v v v v v v v app.j2ee.websphere.WebSphereLDAPUserRegistry app.j2ee.websphere.WebSphereLibraryRef app.j2ee.websphere.WebSphereMQJMSDestination app.j2ee.websphere.WebSphereMQJMSQueue app.j2ee.websphere.WebSphereMQJMSTopic app.j2ee.websphere.WebSphereNamedEndpoint app.j2ee.websphere.WebSphereNode app.j2ee.websphere.WebSphereNodeAgent app.j2ee.websphere.WebSphereServlet app.j2ee.websphere.WebSphereServer app.j2ee.websphere.WebSphereSessionTuningParams app.j2ee.websphere.WebSphereSharedLibrary
47
See the TADDM Administrator's Guide for information about configuring for script-based discovery.
Limitations
Some function that is provided by the WebSphere sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. Application descriptor discovery is not supported. The following model objects are not supported: v app.j2ee.websphere.WebSphereCluster v v v v v app.j2ee.websphere.WebSphereConfiguredConnection app.j2ee.websphere.WebSphereConnector app.j2ee.websphere.WebSphereConnectorModule app.j2ee.websphere.WebSphereCustomUserRegistry app.j2ee.websphere.WebSphereDynamicCache
48
49
For more information about Discovery Profiles, see the Using topics in the IBM Tivoli Application Dependency Discovery Manager information center.
Sensor properties
shallowDiscoveryLevel, mediumDiscoveryLevel, deepDiscoveryLevel The WebSphere sensor has three discovery levels, shallow, medium, and deep. By default the shallow discovery level is enabled. To modify the discovery level value, select one of the following choices: v To enable medium discovery, double-click the value of mediumDiscoveryLevel and change false to true. v To enable deep discovery, double-click the value of deepDiscoveryLevel and change from false to true. If the deepDiscoveryLevel is set to true, it runs a deep discovery regardless of whether shallow and medium discoveries are set to true or false. v The following list contains the information that is captured at each discovery level. Shallow discovery discovers the following components: - Application descriptor files - Cell, node, server names - Cell, node, server type - Host system - JVM runtime version for every running server - Product name and version - Root directory Medium discovery discovers the following components: Clusters Configuration files Connections Deployed connector modules Deployed EJB modules Deployed J2EE applications Deployed web modules Efixes EJB containers End points JVM settings
- Ports - Process definition - Process monitoring policy - Process pools - Security, SSL settings, and user registries - Virtual hosts - Web containers Deep discovery discovers the following components: - Cell, node, server, cluster JDBC providers, JDBC data sources, and JDBC dependencies
50
Custom properties Deployment descriptors for J2EE applications and modules JMS providers and JMS destinations Shared libraries Variables
- Web services - Dynamic cache service settings for servers and dynamic clusters traceSpecification Sets the trace specification string for enabling trace logging of the WebSphere client code called by the TADDM WebSphere sensor. sample value - Admin=all=enabled Caution: The preceding value generates verbose trace logging. Not setting any value prevents trace logging. traceOutputFile Allows you to specify the full path name of the output file to be used for logging trace output. Leave this property blank if tracing is not required. TADDM user must have permission to create the output file. ffdcLogDirectory Enables FFDC logs of the WebSphere client code called by the WebSphere sensor for troubleshooting purposes. FFDC logs capture the failure path through the WebSphere client code in a subdirectory named ffdc in the directory specified in this property. Not setting a value ensures that FFDC is not enabled. The directory must exist and the TADDM user must have write access.
51
v If you need only a user name to log on to the Admin Console, security is disabled. v If you need a user name and password to log on to the Admin Console, security is enabled. v If the connection to the Admin Console is through https (look at the URL in your web browser), you need the certificates.
Certificate setup
If security is enabled when discovering WebSphere Application Server, TADDM requires that SSL certificates are set in the access list entries. TADDM supports PKCS12 and JKS certificate store types. The truststore and keystore files must be present on the computer running the TADDM console, not the TADDM server. Truststore and keystore files are typically found in the $PROFILE_HOME/etc directory on the system where WebSphere Application Server is installed. By default, the following files are certificate stores: v PKCS12 $PROFILE_HOME/etc/trust.p12 $PROFILE_HOME/etc/key.p12 v JKS $PROFILE_HOME/etc/DummyClientTrustFile.jks $PROFILE_HOME/etc/DummyClientKeyFile.jks The default passphrase for these files is WebAS. You can also create truststore and keystore files by downloading certificates using the WebSphere Application Server console. TADDM requires a truststore with signer certificate only for connecting with dmgr, in the case of WebSphere Application Server Network Deployment (ND), and server1, in the case of a stand-alone server. Because of the restrictions of the JMX protocol, which is used to retrieve data from WebSphere Domain Manager or from a stand-alone server (certificates caching per session), TADDM can handle only one truststore file for a single discovery. The certificates that are stored in the truststore file are loaded when connection with WebSphere Application Server is established. Only those certificates can be used by TADDM during the entire discovery, so if certificates from several truststores are required, attaching them separately into appropriate access list entries won't work. You must export the original truststores to a single file. When all necessary entries for each WebSphere server are created in the TADDM access list (one for each different login/password combination for discovered WebSphere servers), the very first one must have the exported truststore and keystore files attached. To create a pair of keystore and truststore files (for PKCS12, the .p12 files, and for JKS, the .jks files) that contain all required certificates, complete the following steps: 1. Extract all certificates from the common keystore or truststore for each server. To do this, complete the following steps: a. In the WebSphere Application Server Admin Console, click Security > SSL certificate and key management. b. Click Key stores and certificates. c. Click NodeDefaultTrustStore.
52
d. Click Signer certificates. e. Select a signer certificate, and click Extract. f. Enter a unique path and file name for the signer certificate, for example C:\temp\signer1.arm. g. Click OK. h. Repeat this procedure for each signer certificate in the truststore. i. Repeat this procedure for all servers that are to be discovered. 2. If you are using JKS truststores, add the exported signer certificates to the .jks files. To do this for the default DummyServerTrustFile.jks and DummyClientTrustFile.jks files, complete the following steps (if you are using PKCS12 truststores, follow the same procedure for key.p12 and trust.p12 files): a. To open the key management utility, iKeyman, run ikeyman.sh, or ikeyman.bat, from the WebSphere_Root/profiles/dmgr_profile/bin directory. b. Click Key Database File > Open. c. Select the DummyServerTrustFile.jks file from one of the following directories: v WebSphere_Root/profiles/dmgr_profile/etc v WebSphere_Root/profiles/stand-alone_server_profile/etc d. When prompted for a password, type WebAS. e. Click Add, and select one of the signer certificates that you extracted in step 1. f. Repeat the previous step for each signer certificate you must add. g. Repeat this procedure to add the exported signer certificates to the WebSphere_Root/profiles/dmgr_profile/etc/DummyClientTrustFile.jks file. 3. Retrieve the client side SSL certificates from the WebSphere Application Server. If new certificates are not generated, the default ones DummyClientTrustFile.jks and DummyClientKeyFile.jks, or trust.p12 and key.p12, are typically located in one of the following directories: v WebSphere_Root/profiles/dmgr_profile/etc v WebSphere_Root/profiles/stand-alone_server_profile/etc The default passphrase for dummy files is WebAS. 4. If you need to use different certificates, do not attempt to edit the certificates. Delete the old access list entry and create an appropriate access list entry.
53
This helps to determine if the system is ND or stand-alone WebSphere Application Server. If read access to this file is not available, the sensor continues and uses JMX to determine whether it is an ND or stand-alone WebSphere Application Server. $WAS_ROOT/config/cells/cell_name/nodes/node_name/serverindex.xml (for ND, node_name is the dmgr's node, for stand-alone mode, there is only one node) This helps to determine the port on which the JMX SOAP connector is listening. If read access to this file is not available, the sensor attempts to set up a JMX connection by cycling through all the listen ports of the WebSphere Application Server server/dmgr being discovered. The ports are tried in ascending order since this method results in quicker identification of the JMX port.
54
WAS_ROOT_DIR The directory path where the WebSphere Application Server is installed. WAS_VERSION The version of the WebSphere Application Server, which can be found in the product file in the <WebSphere Root Directory>/properties/version directory. SOAP_CONNECTOR_PORT The port number is retrieved from the serverindex.xml file for the SOAP_CONNECTOR_ADDRESS endpoint name. For example, <WebSphere Root Directory>/profiles/<app server or dmgr>/conf/cells/<cell name>/nodes/<node name> If the resource is a deployment manager, use the serverindex.xml file with the following value specified: serverType="DEPLOYMENT_MANAGER". If the resource is stand-alone component, use the serverindex.xml file with the following value specified: serverType="APPLICATION_SERVER"
Chapter 2. Application sensors
55
RMI_CONNECTOR_PORT The port number is retrieved from the same serverindex.xml file used to find the soap port, where the endpoint name is BOOTSTRAP_ADDRESS. JMX_LISTEN_IP_ADDRESS The IP address that is used to connect through JMX. Typically this address is the same IP address as the WebSphere server. HOST_MAPPINGS A list of mappings between the host name and IP address for the WebSphere Application Server or Deployment Manager and each distributed Node Agent. HOST_MAPPING One host mapping consisting of a host name, primary IP address, and IP address. HOST_NAME The fully qualified domain name. PRIMARY_IP_ADDRESS The primary IP address that the host name resolves to. IP_ADDRESS The IP address that the host name resolves to, if different from the primary IP address. 2. Place the .xml files in the $COLLATION_HOME/var/dla/zos/was directory. If the directory does not exist, create the directory. The scope of discovery is controlled by the files in this directory. If discovery of a particular WebSphere server is no longer needed, the file must be removed from this directory or renamed without the .xml extension. 3. Create a new sensor configuration file when you run the WebSphere seed sensor. Change the location of the XML seed file using the following two tags: <fileName> Set this tag to the directory where the WebSphere XML seed files are located. <scope> Set this tag to the IP address of the TADDM server where the WebSphere XML seed files are located. Related reference: Installing the WebSphere Application Server seed utility for the z/OS DLA on page 57 To discover the WebSphere product on a z/OS system, use the WebSphere Application Server seed utility for the z/OS DLA. This utility creates the XML seed files from the IDML book. If you do not use this utility, you must manually create the XML seed files.
56
4. In the Access List, add the access credentials of the server where the WebSphere seed file is located. 5. If security is enabled for the WebSphere server being discovered, add the credential entry for the WebSphere server. You also need the client-side SSL certificate when creating the Access List entry. This certificate must be exported from the mainframe security product for example, Resource Access Control Facility (RACF) and transferred to a tool for maintaining digital certificates. Use this tool for example iKeyman, to generate a JKS or PKCS12 file. This file contains the client-side SSL certificate in a format that can be used by TADDM. The JKS or PKCS12 file must then be used for the SSL settings in the TADDM WebSphere Access List entry for both keystore and truststore certificates. 6. Complete the following steps: a. Configure the IdmlFileUDS sensor using the Discovery Management Console: In the Discovery Profiles window, click IdmlFileUDS. Click New. Type the sensor configuration name and description. Select Enable Configuration. Double-click /data/latest/dist/var/dla/zos/was and type the location of the WebSphere XML seed files. This location is the server where the WebSphere seed file is located. 6) Double-click 0.0.0.0 and type the IP address of the machine on which the seed file is located. b. Create a discovery profile that includes the following sensors: 1) 2) 3) 4) 5) v Anchor Sensor v Sensor name entered in step a. (The modified IdmlFileUDS sensor created previously.) v PortSensor v PingSensor v v v v SessionSensor GenericServerSensor WebSphereIdmlSeedSensor WebSphereCellSensor
v WebSphereNodeSensor v WebSphereSensor (select this sensor instead of WebSphereCellSensor and WebSphereNodeSensor only if com.collation.websphere.performance.setting=false) The sensors can require additional sensors to be enabled in the profile by default, enable all additional sensors. c. Save the configuration file. 7. Run the discovery and select the scope to include the server and the discovery profile that you created.
Installing the WebSphere Application Server seed utility for the z/OS DLA
To discover the WebSphere product on a z/OS system, use the WebSphere Application Server seed utility for the z/OS DLA. This utility creates the XML seed files from the IDML book. If you do not use this utility, you must manually create the XML seed files.
Chapter 2. Application sensors
57
To download the utility, complete the following steps: 1. Go to the Tivoli Open Process Automation Library (OPAL) site at http://www.ibm.com/software/tivoli/opal. 2. Enter the following search criteria: WebSphere Application Server seed utility for the z/OS DLA. 3. From the search results, click WebSphere Application Server seed utility for the z/OS DLA. 4. Follow the instructions on the Web page to download the utility. After downloading the utility, read the documentation for installing and using the utility.
58
9.48.158.37:8,880 - ADMC0016E: The system cannot create a SOAP connector to connect to host 9.48.158.37 at port 8880... v ERROR cdb.WebSphereJMXUtils - An error occurred, unable to establish a repository connection using the credentials raleigh-was60: com.ibm.websphere.management.exception.AdminException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the getServerConfig operation on FileTransferServer MBean because of insufficient or empty credentials.
These errors can occur for any of the following reasons: v No credentials exist in the access list for the WebSphere Application Server. v In the credentials for the WebSphere Application Server, the certificates are not correct or have not been entered through the access list. v In the credentials for the WebSphere Application Server, the password is incorrect. Solution Add the credentials in the access list for the WebSphere Application Server. Correct the certificates, enter the certificates through the access list, or provide the correct password.
This type of error indicates the following problems: v A missing or incorrect certificate or an incorrect user ID and password. The following example shows a sample root cause:
[SOAPException: faultCode=SOAP-ENV:Client; msg=Error opening socket: javax.net.ssl.SSLHandshakeException: certificate expired; targetException=java.lang.IllegalArgumentException: Error opening socket: javax.net.ssl.SSLHandshakeException: certificate expired]
v A firewall that is preventing a connection to the WebSphere Application Server through the SOAP port. v The WebSphere Application Server might not be in a good state, even though the process shows up in the process table or Windows services list. To test the state of the WebSphere Application Server, try to connect to it using the wsadmin WebSphere administrative utility. If the wsadmin utility fails, the sensor has problems also. Solution Run one of the following programs, which tests the JMX connection to verify credentials and connectivity: v For Linux, Solaris, AIX, and Linux on System z operating systems: $COLLATION_HOME/bin/testwasconnection.sh. Instructions for running this program are in the testwasconnection.sh file.
59
v For Windows systems: %COLLATION_HOME%\bin\testwasconnection.bat. Instructions for running this program are in the testwasconnection.bat file. Verify that the version of the WebSphere Application Server, that the sensor is to discover matches the version of the WebSphere Application Server JAR files on the TADDM server. If a class is missing, ensure that the correct JAR files are in the correct location.
This error indicates the following problems: v The configuration setup might be corrupted. v A defect in the sensor might cause the missing configuration value to be treated as necessary for discovery progress and might end unnecessarily Solution Check the logs to see what is being queried and whether that value is readable in the WebSphere Application Server console. This error usually occurs because discovery is run overnight, and WebSphere Application Servers are down for maintenance reasons. In this case, restart the server, and try the discovery again.
60
v An error message states that the query cannot be completed. Solution Verify that the WebSphere Application Server is functioning properly.
Sensor does not show as much data as it did in previous releases of TADDM
Problem The Details window for WebSphere cells, nodes, and servers does not show as much detail as it did in previous TADDM releases, and many of the tabs in the window have no data. Solution TADDM implements the following discovery levels: v Shallow v Medium v Deep
61
The default discovery level for the WebSphere Application Server sensor is shallow. To obtain more detail about the WebSphere Application Server, create a discovery sensor configuration for the WebSphereCellSensor sensor, and in the Sensor Configuration window. Set the value of the mediumDiscoveryLevel property or the deepDiscoveryLevel property to true.
WebSphere sensor fails during WebSphere discovery on an AIX operating system due to problems with the AIX ps command
Problem On some AIX operating systems, running the UNIX ps command returns truncated Java CLASSPATH strings. The strings are not recognized by the TADDM WebSphere sensor, resulting in a failed discovery. Solution Upgrade to at least the AIX 5.3. FP5 (5.3.0.50) version. This version and later versions of AIX return the full Java CLASSPATH strings.
Solution Discoveries involving the sensors related to WebSphere Deployment Manager must have a working DNS. As a workaround, change com.collation.platform.os.disableRemoteHostDNSLookups to true, and ensure that the TADDM server always has the correct DNS search path.
62
available: << ip address of IBM WebSphere application server >> - ADMC0016E: The system cannot create a SOAP connector to connect to host << ip address of IBM WebSphere application server >>
Solution Verify that the problem is with the SSL support in the WebSphere client code. To verify, ensure that the WebSphere access list entry for this WebSphere Server is first in the access list (before any other WebSphere credentials). If the discovery is successful, import all the WebSphere certificates from the different servers into one truststore. Having multiple access list entries with different user IDs and passwords is acceptable. However, all the access list entries must specify the same truststore, which contains all the certificates. For additional information, see Configuring the access list on page 51.
WebSphere JDBC driver sensor cannot connect to the target host and the following message is displayed: CTJTD0796E
Problem During the discovery, the WebSphere JDBC driver sensor cannot establish a connection with target host and the CTJTD0796E error message is displayed. Solution The following situations are possible reasons for this error: v SSH connection could not be established with the host. v A connection with the host was established, but the user did not have the appropriate privileges to run the WebSphere setupCmdLine script. v A connection with the host was established, but the user did not have the appropriate privileges to run the Java command. You must check the sensor logs files to determine which of these situations has occurred. If the sensor fails and the warning CTJTD0798W is displayed in the log files, ensure that the user specified in the WebSphere SSH access list entry has the appropriate privileges to run the WebSphere setupCmdLine script. If the sensor fails and the warning CTJTD0799W is displayed in the log files, ensure that the user specified in the WebSphere SSH access list entry has the appropriate privileges to run the Java command.
63
Prerequisites
IBM WebSphere eXtreme Scale must be running on the target computers. The path to the configuration file, specified by the -objectgridfile parameter, must be absolute.
Security issues
The user must have permission to perform the following tasks: v Get the complete list of processes, including Java virtual machine (JVM) processes, running on the target system. v Read the configuration file specified by the -objectgridfile parameter, typically objectGrid.xml. v Read any XML files, script files or properties files in the same directory as the configuration file specified by the -objectgridfile parameter, if this information is to be captured. v Run the JVM that runs the eXtreme Scale node with the -version parameter, to get runtime environment version information. v Read the orb.properties configuration file, which is in the lib directory of the JVM.
Limitations
The following limitations apply: v Only those eXtreme Scale nodes that are using separate JVMs as containers for eXtreme Scale caches are discovered. Caches that use special web applications as containers for eXtreme Scale nodes are not discovered. v JVMs that provide catalog services for eXtreme Scale nodes are not discovered.
64
v If more than one JVM process is started with the same node name and the same copy of the configuration file specified by the -objectgridfile parameter, the sensor does not recognize that they are separate nodes, and the nodes are merged. v The sensor looks for configuration files only in the same directory as the configuration file specified by the -objectgridfile parameter, and its subdirectories. Only files with one of the following extensions are recognized: .xml .sh .props .properties You cannot configure the file extension recognized. v The sensor does not parse the configuration files, but captures the entire contents of each file. v When checking the -objectgridfile parameter, the sensor ignores case.
65
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.
66
6. Click OK to return to the Discovery Profiles window. 7. In the Discovery Profiles window, click Save. 8. Choose this discovery profile when running a discovery. For more information about Discovery Profiles, see the Using topics in the IBM Tivoli Application Dependency Discovery Manager information center.
67
Security issues
The TADDM server requires the following login information: v System login with ability to discover the target computer. v For the WebSphere MQ server on a UNIX system, the WebSphere MQ user login and password used to log on to the MQSC console.
Limitations
Some function that is provided by the WebSphere MQ Server sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. Application descriptor discovery is not supported.
68
69
v The second matches the target queue manager name. If the custom channel naming does not contain the source queue manager name, for example, TO.TARGET_MANAGER, the first group can be set to an empty value, for instance, ()TO.(.*). The source queue manager name is not compared with the sender channel parent queue manager name in that case. If not set, the default value for the <REGULAR_EXPRESSION) is CH\\.(.*?)\\.TO\\.(.* The following properties are used for generating display names for the QueueManager. com.collation.discover.agent.MQQueueManager.Use ListenningIp=true Sets the QueueManager name; the default value is false. <FQDN>:<QUEUE_MANAGER_NAME> - First non-empty Fully Qualified Domain Name (FQDN) or IP from the first listening MQListener is used com.collation.discover.agent.MQQueueManager.UseIpFromConnections=true The default value is false. <FQDN>:<QUEUE_MANAGER_NAME> - First non-empty FQDN (or IP) taken from LOCLADDR attribute of the ServerConnection is used. com.collation.discover.agent.MQQueueManager.UseEmptyHostName=true If the FQDN is not present, the first non-empty FQDN (or IP) taken from the LOCLADDR attribute of the ClientConnection is used. The default value is false. <QUEUE_MANAGER_NAME> - The QueueManager name without the FQDN is used. com.collation.topobuilder.mq.removerelations If not set, the default value is false. If set to true, dependencies for the WebSphere MQ queue manager are removed if the state is other than running. If none of the preceding properties are set to true (UseListenningIp or UseIpFromConnections did not resolve the FQDN) <HOST_FQDN>:<QUEUE_MANAGER_NAME> - The parent host FDQN is used The following properties are used to specify that the sensor should use the sudo command when running MQ commands on the server. com.collation.discover.agent.MqServerAgent.versionCommand=sudo -u user Specifies that the sensor should use sudo with the specified user name when running the MQ version command. com.collation.discover.agent.MqServerAgent.statusCommand=sudo -u user Specifies that the sensor should use sudo with the specified user name when running the MQ dspmq command. com.collation.discover.agent.MqServerAgent.mqscCommand=sudo -u user Specifies that the sensor should use sudo with the specified user name when running the MQ runmqsc command. Each of the preceding properties can be scoped to a particular operating system type, IP address, or both, as in the following example:
com.collation.discover.agent.MqServerAgent.mqscCommand.Linux.1.2.3.4=sudo -u mqm
70
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
71
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.
72
Solution Ensure that the JBoss JAR files for the JBoss server version you are running are present in the dist directory with read access for the TADDM server user.
LDAP sensor
The LDAP sensor discovers LDAP servers.
Limitations
The sensor discovers LDAP only when the LDAP service listens on port number 389 and accepts plain text authentication. Discovery cannot occur if LADP server requires encryption or a port number other than 389 is used.
Solution The LADP server requires encryption. The LADP sensor cannot carry out a discovery if the LADP server requires encryption, disable the encryption on the LADP server.
73
Prerequisites
The MS Cluster sensor requires: v Successful discovery of Windows computer systems v The Cluster Server ClusSvc service, must be running v Using the TADDM Windows Management Instrumentation (WMI) provider, WMI read access to the root/mscluster namespace must be granted. If the discovery of the Windows computer systems succeeded, this WMI read access is granted by default. Administrative-level access is preferable.
Limitations
The scope of discovery must contain the IP address of at least one of the MS Cluster nodes or mention the cluster IP address. A node is any computer that is part of the cluster.
v MaxNumberofNodes v MaxQuorumArbitrationTime
74
v v v v v v v v v v v v v v v v v v
MinQuorumArbitrationTime Name Nodes PlumbAllCrossSubnetRoutes PublicNetworks QuorumLogFileSize QuorumPath QuorumType RegroupOpeningTimeout RegroupPruningTimeout RegroupStageTimeout RegroupTick RequestReplyTimeout ResourceDllDeadlockPeriod ResourceGroups Resources SameSubnetDelay SameSubnetThreshold
v SecurityLevel v WitnessDatabaseWriteTimeout v WitnessRestartInterval app.MsFailoverCluster.MsClusterNode v Description v EnableEventLogReplication v InitialLoadInfo v LastLoadInfo v Name v NodeHighestVersion v NodeLowestVersion v System app.MsFailoverCluster.MsClusterResource v AppServers v CryptoCheckpoints v v v v v v v v v v v DeadlockTimeout DebugPrefix DeleteRequiresAllNodes DependsOnResources Description HasSeparateMonitor IpAddresses IsAlivePollInterval IsCoreResource IsLocalQuorumCapable IsPersistentState
Chapter 2. Application sensors
75
v v v v v v v v v v v
IsQuorumCapable LooksAlivePollInterval Name PendingTimeout RegistryCheckpoints RestartAction RestartDelay RestartPeriod RestartThreshold RetryPeriodOnFailure Type
app.MsFailoverCluster.MsClusterResourceGroup v AntiAffinityClassNames v AutoFailbackType v Description v FailbackWindowEnd v FailbackWindowStart v FailoverPeriod v FailoverThreshold v IsPersistentState v Name v Parent v Resources
76
WMIDiag The WMIDiag utility is available at the following Web site: http://www.microsoft.com/downloads/ details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d &displaylang=en Follow the instructions to install and run the utility, and verify that WMI is working correctly.
Prerequisites
The account TADDM uses to access the windows gateway must have an Active Directory account and not a local account on the gateway.
Limitations
Note the following limitations: v In an Exchange Server clustering environment, the sensor discovers only the active cluster node. v The sensor discovers the virtual servers for only the SMTP and X400 protocols.
77
78
1. Start the Exchange System Manager on the computer where the Exchange Server is installed. 2. In the list of servers, verify that the local Exchange Server is displayed. 3. If the local Exchange Server is not displayed, verify that the Microsoft Exchange Server is installed and running correctly. v The Exchange Server is installed as a cluster node, but it is currently inactive. For Microsoft Exchange Server 2003, complete the following steps: 1. Start the cluster administration program on the computer where the Exchange Server is installed as a cluster node. 2. Check which Exchange resource is assigned to the Exchange virtual server.
Solution This error message means that no output was retrieved through the Windows Management Instrumentation (WMI). For Microsoft Exchange Server 2003, complete the following steps: 1. 2. 3. 4. Run the services.msc program on the target Windows system. Restart the Microsoft Exchange Management service. Run the discovery again. If the problem persists, see the sensors/ ExchangeServerSensor-*.log file to determine if the problem is WMI related.
Microsoft Exchange Server 2007, 2000, and 5.5 are not discovered
Problem The Exchange Server sensor terminates with the following error message: CTDTD0812E No Microsoft Exchange Server is found. Solution This error message means that no Exchange Server object exists in the output that was retrieved through the Windows Management Instrumentation (WMI). For Microsoft Exchange Server 2003, complete the following steps: 1. Run the services.msc program on the target Windows system. 2. Restart the Microsoft Exchange Management service. 3. Run the discovery again. 4. If the problem still persists, see the sensors/ ExchangeServerSensor*.log file to determine if the problem is WMI related.
79
Solution The message typically means that the TADDM service account does not have the appropriate permission to access the required WMI namespace. For Microsoft Exchange Server 2003, complete the following steps: 1. Ensure that the TADDM service account has full permission for the following WMI namespaces:
Root\CIMV2 Root\CIMV2\Applications\Exchange Root\MicrosoftExchangeV2
configure the permission, complete the following steps: Click Start > Run > Open wmimgmt.msc. Right-click WMI Control (Local), and click Properties. In the WMI Control (Local) Properties window, click the Security tab. d. Click WMI namespace, and click Security. e. In the Security window, select the following permissions to allow the user or group: v Execute Methods v Full Write v Partial Write v Provider Write v Enable Account v Remote Enable v Read Security v Edit Security 2. Ensure that the TADDM service account has enough permission for the Exchange Server and Folder Tree objects. To configure the permission, complete the following steps: a. Click Start > All Programs > Microsoft Exchange > System Manager b. In the Exchange System Manager, expand Servers tree and find the server object to be discovered. c. Right-click the server and select Properties. d. In the Properties window, click the Security tab. e. Click Add, and select the user for the TADDM service account, and click OK. f. In the Permissions for Administrator field, make sure Allow check boxes next to the following permissions is turned on: v Read v v v v v Execute Read permissions List contents Read properties List object
To a. b. c.
v View information store status g. In the Exchange System Manager, expand Folders tree and find the folder tree object to be discovered. h. Do the same operation as described above for the server.
80
Solution The message typically means that the sensor tried to refer to a WMI class that does not exist. Possible causes include that the Exchange Server is not installed correctly, or the version of Exchange Server is not supported. Only Microsoft Exchange Server 2003 is supported. Microsoft Exchange Server 2007, 2000, and 5.5 are not discovered because these versions are not supported.
Prerequisites
The Exchange management tools and the Window PowerShell must be installed on the Exchange Server. To verify that the user account permissions are correct, run the following command on the Exchange Server while logged in as the TADDM discovery account:
C:\> powershell Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin;Get-ExchangeServer
Limitations
In the Exchange Server cluster environment, the sensor discovers only the active mailbox server.
81
The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. app.messaging.exchange.AcceptedDomain v AcceptedDomainName v Default v DistinguishedName v DomainName v DomainType app.messaging.exchange.ActiveSyncVirtualDirectory v v v v v BasicAuthenticationEnabled ClientCertEnabled RemoteDocumentsActionForUnknownServers WebSiteName WebSiteSSLEnabled
app.messaging.exchange.ClientAccess v ClientAuthenticationMethod v ExternalHostName v OutlookAnywhereEnabled v SSLOffloading app.messaging.exchange.TransportServer v AntispamUpdatesEnabled v ConnectivityLogEnabled v ConnectivityLogPath v v v v v v v v v v v v v DelayNotificationTimeout ExternalDNSAdapterEnabled InternalDNSAdapterEnabled MaxOutboundConnections MaxPerDomainOutboundConnections MessageExpirationTimeout MessageTrackingLogEnabled MessageTrackingLogPath OutboundConnectionFailureRetryInterval ReceiveProtocolLogPath SendProtocolLogPath TransientFailureRetryCount TransientFailureRetryInterval
82
v ReportNDRTo v Scope app.messaging.exchange.ExchangeMailbox v Alias v Mailbox v DisplayName v OrganizationalUnit v PrimarySmtpAddress v RecipientTypeDetails v UserDistinguishedName app.messaging.exchange.ExchangeMailboxStore v AllowFileRestore v CopyEdbFilePath v v v v v DeletedItemRetention IssueWarningQuota JournalRecipient LastFullBackup LastIncrementalBackup
v MailboxRetention v MountAtStartup v ProhibitSendQuota v ProhibitSendReceiveQuota v RetainDeletedItemsUntilBackup app.messaging.exchange.ExchangeProtocol v v v v AuthenticatedConnectionTimeout Banner DistinguishedName LoginType
83
v v v v v v v v v v v v
CustomReferralServerList DeletedItemRetention IssueWarningQuota ItemRetentionPeriod LastFullBackup LastIncrementalBackup MaxItemSize MountAtStartup ProhibitPostQuota PublicFolderHierarchy ReplicationMessageSize ReplicationPeriod
v RetainDeletedItemsUntilBackup v UseCustomReferralList app.messaging.exchange.ExchangeServer v ActiveDirectoryDomainName v DistinguishedName v Domain v Edition v ErrorReportingEnabled v ProductID v Site app.messaging.exchange.ExchangeServerRole v RoleName app.messaging.exchange.ExchangeVirtualDirectory v DistinguishedName v ExternalURL v InternalURL v Path v VirtualDirectoryName app.messaging.exchange.MailboxServer v AutoDatabaseMountDial v ForcedDatabaseMountAfter v RedundantMachines app.messaging.exchange.OABVirtualDirectory v PollInterval app.messaging.exchange.OwaVirtualDirectory v v v v v v v ActiveSyncIntegrationEnabled AllAddressListsEnabled BasicAuthentication CalendarEnabled ChangePasswordEnabled ContactsEnabled DefaultDomain
84
v v v v v v v v v v v v v v v v v v
DigestAuthentication FormsAuthentication JournalEnabled JunkEmailEnabled LogonFormat NotesEnabled OwaVersion PremiumClientEnabled PublicFoldersEnabled RecoverDeletedItemsEnabled RemindersAndNotificationsEnabled RulesEnabled SMimeEnabled SearchFoldersEnabled SignaturesEnabled SpellCheckerEnabled TasksEnabled ThemeSelectionEnabled
v UMIntegrationEnabled v WebSiteName v WindowsAuthentication app.messaging.exchange.ReceiveConnector v AnonymousUsersPermission v BasicAuthRequiresTLS v BasicAuthentication v ExchangeAuthentication v ExchangeLegacyServersPermission v v v v v ExchangeServersPermission ExchangeUsersPermission ExternalAuthoritative MutualAuthTLS PartnersPermission
v RemoteIPRanges v TLS v WindowsAuthentication app.messaging.exchange.SendConnector v AddressSpaces v DNSRoutingEnabled v DomainSecureEnabled v IsScoped v SmartHosts v UseExternalDNSRoutersEnabled app.messaging.exchange.TransportRule v Comments
Chapter 2. Application sensors
85
86
Run the services.msc program to check the status of the service or check the status by using Windows Task Manager.
Solution Verify that in the Access List configuration, that the access information (user name and password) is correct. Access permission to the Active Directory domain on which the Exchange server is running, and not the local computer, must be granted.
Prerequisites
To discover the hypervisor and the virtualized guest systems, the hypervisor must be running with Microsoft Windows Server 2008 x64 Edition in the root (parent) partition.
Security issues
The TADDM service account on the target Hyper-V system, must be able to run the wmic command to query the Windows Management Instrumentation (WMI) interface.
87
Enter the following command on one line, from the command-line interface of the target host system (parent partition) to verify:
wmic /namespace:\\root\virtualization path Msvm_VirtualSystemSettingData get SystemName, BaseBoardSerialNumber, ElementName
Limitations
The sensor supports Microsoft Windows 2008 x64 with Hyper-V enabled. The sensor does not support Microsoft Hyper-V Server 2008.
88
The Microsoft HyperV sensor requires a Level 2 discovery of the target host (parent partition) based on Microsoft Windows 2008 x64. Create an access list entry for Computer System (Windows) to discover the computers running Windows Server 2008 with Hyper-V.
Prerequisites
Ensure that the following requirements are met: v Discovery of the computer system must succeed.
89
v The gateway must have the IIS Manager installed. This method ensures that the COM classes are installed. These classes are required by the TaddmTool AdsiDump and AdsiEnum commands. v If IIS Manager is not present, install it using Add/Remove Programs in the Windows Control Panel. Select Windows components > Application Server > IIS > Install IIS Manager. v To discover IIS 7.0 servers, the IIS 6.0 Metabase Compatibility component must be installed on the server. To install, complete the following steps: 1. Click Start > Administrative Tools > Server Manager. 2. In the navigation pane, expand Roles, right-click Web Server (IIS), and then click Add Role Services. 3. In the Select Role Services pane, scroll down to IIS 6 Management Compatibility. 4. Select the IIS 6 Metabase Compatibility check box. 5. In the Select Role Services pane, click Next, and then click Install at the Confirm Installations Selections pane. 6. Click Close to exit the Add Role Services wizard. When the IIS 6.0 Metabase Compatibility component is not installed, errors are displayed in the log file and a deep discovery does not occur.
90
Check whether the TaddmTool program QueryRegistry commands succeeded. Two registry paths are queried. v HKLM\SOFTWARE\Microsoft\W3SVC v HKLM\SYSTEM\CurrentControlSet\Services\W3SVC The first key provides general software information for IIS and the second provides service-related information.
Use one of the following methods to remove the duplicates: v Merge the duplicates in the Data Management Portal. v Manually delete the old configuration items. For more information about merging and deleting discovered configuration items, see the "Discovery tasks" section in the TADDM User's Guide.
NFS sensor
The NFS sensor discovers Network File System (NFS) servers.
91
Prerequisites
Note the following prerequisites: v Discovery of the computer system must succeed. v An Oracle Application Server account must be entered in the access list. v An account with admin privilege is required (read-only ID can work). v Oracle Application Server libraries must be made available on the TADDM server. v Relative paths are relative to $COLLATION_HOME. v Requires two subdirectories: j2ee opmn These files can be copied or NFS mounted from an existing Oracle Application Server installation. The required JAR files on the TADDM server are: j2ee/home/lib/ejb.jar j2ee/home/lib/adminclient.jar j2ee/home/lib/javax77.jar j2ee/home/lib/jmxcluster.jar j2ee/home/lib/jmx_remote_api.jar
v Specify the location of the files in the com.collation.oracleapp.root.dir entry in the collation.properties file. v These files must have read privileges for the collation user.
92
v v v v v v v v v v v v v v v v v v
app.j2ee.MessageDrivenBean app.j2ee.oracleapp.OracleAppCluster app.j2ee.oracleapp.OracleAppConnectorModule app.j2ee.oracleapp.OracleAppDomain app.j2ee.oracleapp.OracleAppEJBModule app.j2ee.oracleapp.OracleAppJ2EEApplication app.j2ee.oracleapp.OracleAppJ2EEServer app.j2ee.oracleapp.OracleAppJ2EEWebSite app.j2ee.oracleapp.OracleAppJDBCConnectionPool app.j2ee.oracleapp.OracleAppJDBCDataSource app.j2ee.oracleapp.OracleAppJDBCDriver app.j2ee.oracleapp.OracleAppJMSDestination app.j2ee.oracleapp.OracleAppJMSServer app.j2ee.oracleapp.OracleAppJSPContainer app.j2ee.oracleapp.OracleAppJTAResource app.j2ee.oracleapp.OracleAppProcessManager app.j2ee.oracleapp.OracleAppResourceAdapter app.j2ee.oracleapp.OracleAppServlet
v sys.ComputerSystem The OracleAppOpmn creates the following model objects: v app.AppConfig v app.ConfigFile v app.j2ee.oracleapp.OracleAppCluster v app.j2ee.oracleapp.OracleAppProcessManager v app.web.oracleapp.OracleAppHTTPServer v core.LogicalContent v v v v enums.StatusEnum net.BindAddress net.IpAddress sys.ComputerSystem
93
Add an entry to the access list for the system running the Oracle Application Server.
94
false. The value must be set to true for the sensor to start. A value of true specifies that the processes that are listening on loopback interfaces are to be ignored. v The Oracle Application Server libraries are not available on the TADDM server. Oracle Application Server libraries must be made available on the TADDM server. Use the following property to specify the location of these libraries: com.collation.oracleapp.root.dir=lib/oracleapp The default value for this property is lib/oracleapp. If the value for this property is a relative directory, the directory is relative to $COLLATION_HOME, as shown in the following example: $COLLATION_HOME/lib/oracleapp. Whether the path is relative or absolute, the path must contain the following two subdirectories: j2ee opmn The Oracle Application Server libraries can be copied, or mounted using the Network File System (NFS), from an existing Oracle Application Server installation. The following list identifies the required jar files: j2ee/home/lib/ejb.jar j2ee/home/lib/adminclient.jar j2ee/home/lib/javax77.jar j2ee/home/lib/jmxcluster.jar j2ee/home/lib/jmx_remote_api.jar j2ee/home/lib/jmxri.jar j2ee/home/oc4jclient.jar opmn/lib/argus.jar opmn/lib/ons.jar opmn/lib/opmnconfig.jar
opmn/lib/optic.jar opmn/lib/repositorycheck.jar
95
Sensor fails in remote server with Name not found error message in log file
Problem The sensor fails and the following error is displayed in the log file:
javax.naming.NameNotFoundException: oc4j:internal/ResourceFinder not found
Solution Add the IP address and host name of the Oracle Application Server to the /etc/hosts file on the TADDM server.
Prerequisites
The SAP CCMS server sensor requires JCo libraries to function. For information about JCo libraries, see the topic Installing the SAP Java Connector (JCo) libraries. Depending on the specific application of SAP NetWeaver systems, you can use the SAP CCMS server sensor, the SAP SLD server sensor, or both to discover this system. SAP applications are installed on two different database schemas depending on the application, and each are accessed by their respective runtime environments. There is a runtime environment for Java instances (Java stack) and one for the Advanced Business Application Programming (ABAP) instances (ABAP stack): v Use the SAP CCMS server sensor to discover information where the SAP NetWeaver system has applications based only on the ABAP stack. v Use the SAP SLD server sensor to discover information where the SAP NetWeaver system has applications based only on the Java stack. v Use the SAP CCMS server sensor, the SAP SLD server, or both sensors to discover information where the SAP NetWeaver system has applications based on both the ABAP and Java stacks.
96
97
S_DATASET Authorization for file access S_LOG_COM Authorization to Execute Logical Operating System Commands S_RZL_ADM CC Control Station: System Administration S_XMI_LOG Internal Access Authorization for XMI Log S_XMI_PROD Authorization for External Management Interfaces (XMI)
Solution The sapjco.jar file should be in the $COLLATION_HOME/ lib/JCo/lib directory, this file path should be in the class path. Look for the following message in the DiscoverManager.log file:
adding this jar file to the list: {jar-file-path}
98
Sensor failed in remote server: JCO.classInitialize (): Could not load middleware layer com.sap.mw.jco.rfc.MiddlewareRFC JCO.nativeInit (): Could not initialize dynamic link library sapjcorfc [Cant find library sapjcorfc (libsapjcorfc.so) in sun.boot.library.path or java.library.path sun.boot.library.path={full-path-list}
Solution Ensure that the libsapjcorfc.so library file is in the $COLLATION_HOME/ lib/JCo/operating system (Linux, AIX, or Solaris) path. Also ensure that this path is present in the full-path-list for sun.boot.library.path that is mentioned in the preceding message. If the path is present, the problem might be due to library dependencies that have not been met. Run the ldd command against the libsapjcorfc.so library file to get a list of the library dependencies, and verify that your environment supports these dependencies.
This error can occur for one of the following reasons: v No access list is provided for the sensor. v The sensor cannot successfully connect to the IP address using the access list information that is provided by the user. Solution If you provided the necessary access list credentials, verify the following items: v Ensure that the user ID meets the specified minimum authorization requirements. v Ensure that the SAP ABAP server is accessible. v Look for the following message in the local-anchor*.log, and ensure that the username and client-id that are specified are the ones that you set:
Checking connection with username: {username} and clientID: {client- id}
You can also provide SAP_ALL authorization to the user and try to connect to the SAP ABAP server directly through the SAP GUI, if it is available.
Prerequisites
The SAP System Landscape Directory (SLD) server must be running.
99
Depending on the specific application of SAP NetWeaver systems, you can use the SAP CCMS server sensor, the SAP SLD server sensor, or both to discover this system. SAP applications are installed on two different database schemas depending on the application, and each are accessed by their respective runtime environments. There is a runtime environment for Java instances (Java stack) and one for the Advanced Business Application Programming (ABAP) instances (ABAP stack): v Use the SAP CCMS server sensor to discover information where the SAP NetWeaver system has applications based only on the ABAP stack. v Use the SAP SLD server sensor to discover information where the SAP NetWeaver system has applications based only on the Java stack. v Use the SAP CCMS server sensor, the SAP SLD server, or both sensors to discover information where the SAP NetWeaver system has applications based on both the ABAP and Java stacks.
com.collation.platform.os.ignoreLoopbackProcesses=true The default value is true, which means that the processes that are listening on loopback interfaces are ignored. Therefore, if a server is listening only on the loopback IP address (127.0.0.1), and not on any other externally available IP address, that server will not be discovered. This property controls the discovery of external IP addresses. If the value of this property is set to false, all processes with listening ports are considered for discovery.
100
You must set this property to true if you want to discover an Oracle Application Server or the WebLogic sensors. For example, if the WeblogicServerVersionSensor sensor tries to start using a local host address, this property must be set to true. com.collation.discover.agent.SLD.PoolSize This property specifies the maximum number of connection pools to be maintained alive to an SLD server. These connections can be reused for additional requests. The default value is 16. com.collation.sudoCommand This property specifies the sudo command name. The default value is sudo.
101
Solution This message indicates that there is a problem with Windows Management Instrumentation (WMI) service. See the Windows computer system sensor Troubleshooting the sensor topic for information about WMI problems and solutions.
Limitations
The sensor does not discover information about SMS Server client computer systems as CDM ComputerSystem instances but instead as CDM SMSCollectionClients instances. Therefore, the discovery of an SMS Server cannot be used in place of direct discovery of the hosts that are part of the SMS Server infrastructure.
102
com.collation.discover.agent.SMSServerAgent.GetClients If set to true, information about SMS collection clients is captured by the sensor and stored as instances of the CSM SMSCollectionClients class. The default value is false. com.collation.discover.agent.SMSServerAgent.MaxNrClients The maximum number of clients about which information is captured by the sensor. The default value is 100.
SysImager sensor
The SysImager sensor discovers SystemImager High Performance Computing (HPC) clusters.
Prerequisites
The GenericComputerSystemSensor, along with prerequisite sensors, must be enabled in the discovery profile used for discovering the SysImager cluster.
v sys.hpc.cm.SysImagerOverride
103
clusterXMLFileLocation The location of the SysImager cluster configuration file. The default value is /etc/systemimager/cluster.xml. clusterConfigCommand The command to display configuration information about the SysImager cluster. The default value is si_clusterconfig -g. lsImageCommand The command to display images of the SysImager cluster. The default value is si_lsimage -v. imagesDiscoveryMode This property is not used. overridesDiscoveryMode The depth of file capture for overrides. The valid values are as follows: v 0: No file information is captured. v 1: Only the file name and file information are captured. v 2: All file information and content are captured. The default value is 1. overridesDiscoveryPattern The filename pattern for files under the overrides directory. The default value is "*". preInstallScriptsContent The depth of file capture of the scripts executed before install. The valid values are as follows: v 0: No file information is captured. v 1: Only the file name and file information are captured. v 2: All file information and content are captured. The default value is 1. postInstallScriptsContent The depth of file capture of the scripts executed after install. The valid values are as follows: v 0: No file information is captured. v 1: Only the file name and file information are captured. v 2: All file information and content are captured. The default value is 1. nodesScope The scope of the IP addresses to which the SysImager node sensors are restricted. doPingNodes Specifies whether ping sensors are run against discovered SysImager nodes.
104
Security issues
The user account for discovering Computer Systems is also used for running Veritas commands. By default, execute permission on the Veritas Cluster directory and commands is required. The sensor uses the following commands: v hastatus v haclus v v v v v hasys hares hagrp hatype hauser
Before running Veritas commands, a login to the cluster is performed on systems that support the Veritas halogin command. These are UNIX systems with VCS version 4.1 and higher. The sensor logs in using the user name and password from the High Availability Solutions access list entry. To specify that the sensor should use sudo when running Veritas Cluster Server commands on Linux or UNIX systems, configure the appropriate parameters in the collation.properties file. To run the commands without using the sudo command, the TADDM service account must be a member of the Veritas Admin Group on the target. You must configure sudo ndd with NOPASSWORD for the access user.
105
106
v com.collation.discover.agent.command.hastatus.Linux=sudo /opt/VRTSvcs/bin/hastatus v com.collation.discover.agent.command.hastatus.Linux.192.168.1.1=sudo /opt/VRTSvcs/bin/hastatus Specify the sudo option for an operating system only if it required for all systems running that operating system; otherwise, specify the option only for the specific IP addresses where the sudo command is configured. You must configure sudo ndd with NOPASSWORD for the access user. On each target system for which privilege escalation is needed, configure the sudo command with the NOPASSWD option. Otherwise, your discovery hangs until the TADDM server times out.
107
VMware ESX servers, which are discovered by the VMware ESX and Virtual Center server sensors, are merged after the discovery. In the Discovery Management Console, a VM (virtual machine) is represented by a computer system icon that is blue and transparent. The Virtual Center server sensor uses the VMware API to discover data, and the VMware API collects the following data: v Attribute data that is required to match naming rules and to create a valid stand-alone VM instance v Certain basic information that the VMware ESX server provides through the vmware-cmd command v The attribute primaryMACAddress, which is required to reconcile the shallow virtual instance with any physical instance that can be discovered v The attribute vmwareUUID, which is required to reconcile the virtual computer instances that are discovered before and after migrations using VMotion. There are four user scenarios for a Virtual Center and ESX server discovery: v All-inclusive: The discovery scope contains ESX and Virtual Center servers. The result displays the ESX and Virtual Center servers. ESX servers that are managed by the Virtual Center servers are displayed in one of the data centers or clusters in the virtual center. All virtual and physical instances, discovered by the Virtual Center and ESX sensors are reconciled. The physical instances have a virtual attribute set to true. v ESX server Only: The discovery scope contains ESX servers. The result displays the ESX servers that are discovered by the ESX sensor. ESX servers with typical attributes for example, model are displayed. The Virtual Center sensor is not started. v Virtual Center Server Only: The discovery scope contains Virtual Center servers. The result displays the ESX servers and virtual computers that are discovered by the Virtual Center sensor. v Virtual Center and VM: The discovery scope contains Virtual Center servers and all virtual computers. The results display all the virtual computers, with all the physical, and virtual attributes set to true. The virtual computers are displayed in the Virtual Systems tab of the respective ESX server.
Prerequisites
The VMware Virtual Center server service is running on the target windows computer.
Security issues
To discover the VMware Virtual Center server, you must set read-only permissions for the TADDM service account. The service account must have administrator privileges.
108
The sensor creates the following model objects. The attributes that are associated with each model object are shown below the model object name. net.IpInterface (for ESX server only) v Name v IpAddress net.L2Interface v Name (for ESX server only) v Index (for Virtual Machines) v HwAddress process.CPUResourcePool v Name v Label v Limit v Reservation v SharesLevel v SharesValue process.MemoryResourcePool v Name v Label v Limit v Reservation v SharesLevel v SharesValue relation.AllocatedTo v Source (MemoryResourcePool or CPUResourcePool) v Target (Memory or CPU) relation.DonatedTo v Source (for ESX server only) v Target (MemoryResourcePool or CPUResourcePool) sys.CPU v NumCPUs v Parent sys.DNSResolveEntry (for ESX server only) v ServerIP v Parent sys.Memory v MemorySize v Parent sys.NFSFileSystem v serverName v MountPoint v Type v Capacity
Chapter 2. Application sensors
109
v v v v v
sys.unix.UnixFileSystem (for Virtual Machine File System) v MountPoint v Type v Capacity v v v v v AvailableSpace MaxFileSize StorageExtent FileSystemBlockSize MaxBlocks
sys.vmware.DataCenter v Name v Label v Parent v Systems v Clusters v VirtualSwitches sys.vmware.VirtualCenter v Name v Host v v v v UID VersionString ApiVersion Vendor
v BuildLevel v VirtualCenterPort v MaxDBConnections v ClientTimeoutNormal v ClientTimeoutLong v WebServiceHttpPort v WebServiceHttpsPort sys.vmware.VMWareCluster v Name v Label v DPMEnabled v v v v v DRSEnabled HAEnabled Parent RootMemoryResourcePool RootCPUResourcePool
110
sys.vmware.VMWareDataStore v Name v Label v Type v DataStoreURL v v v v v v v Capacity FreeSpace IsAccessible AccessMode IsMultipleHostsAccess BasedOn DataCenter
sys.vmware.VmwareESX v OSName v OSVersion sys.vmware.VMWarePortGroup v ActiveUplinks v L2Interfaces v Name v Parent v StandbyUplinks v Uplinks sys.vmware.VmwareUnitaryComputerSystem v Name v v v v Fqdn ObjectType Manufacturer Model
v CPUSpeed v CPUType v LifecycleState v NumCPUs v MemorySize v v v v v AvailableMemoryForAllVMs CurrentMemoryForAllVMs SwapMemorySize ServiceConsoleMemorySize VmotionEnabled DataCenter Name MTU NumPorts NumPortsAvailable
Chapter 2. Application sensors
sys.vmware.VMWareVirtualSwitch v v v v v
111
v v v v v
sys.vmware.VMWareDVUplink v L2Interfaces v Name Multiple virtual machines, such as the following operating systems and virtual systems: sys.darwin.Darwin sys.darwin.DarwinUnitaryComputerSystem sys.dos.Dos sys.dos.DosUnitaryComputerSystem sys.freebsd.FreeBSD sys.freebsd.FreeBSDUnitaryComputerSystem sys.linux.Linux sys.linux.LinuxUnitaryComputerSystem sys.netware.Netware sys.netware.NetwareUnitaryComputerSystem sys.sun.Solaris sys.sun.SunSPARCUnitaryComputerSystem sys.windows.WindowsComputerSystem sys.windows.WindowsOperatingSystem The following attributes are associated with these model objects: v uuid v v v v v VMID OSName Fqdn (if VMware Tools are running on virtual machine) MemorySize NumCPUs
v FaultTolerance
112
1. From the VMware Infrastructure Client, log on to the VMware Virtual Center server using root credentials. 2. Click the Permissions tab. 3. Right-click in the Permissions pane and click Add Permissions. The Assign Permissions window is displayed. 4. In the Assigned Role area, select Read-Only from the list. 5. In the Users and Groups area, click Add. The Select Users window is displayed. 6. Select the non-root user that you want to include in this role. Click Add and click OK. 7. In the Assign Permissions window, click OK to apply the changes.
Serial number and System ID are blank in the Details panel of the VMware ESX server
Problem The attributes Serial number and System ID are blank in the Details panel of the VMware ESX server. The attributes for the file system are not discovered. Solution The attributes are not displayed because the information is not available from the API. For the L2Interface layer, only the name and hardware addresses are collected. Verify that the ESX server and Virtual Center server are included in the discovery scope. Check the credentials, to ensure that the correct permissions are used for accessing the ESX server and Virtual Center server, and run the discovery again.
Chapter 2. Application sensors
113
Elements managed by the VMware Virtual Center server are not discovered
Problem Elements are not discovered on VMware vCenter Server Version 4.1 running on Microsoft Windows Server 2003. The following error messages exist: v The VirtualCenterServer log contains:
AxisFault faultCode: {http://xml.apache.org/axis/}HTTP faultSubcode: faultString: (503)Service Unavailable faultActor: faultNode: faultDetail: {}:return code: 503 503 Service Unavailable {http://xml.apache.org/axis/}HttpErrorCode:503 (503)Service Unavailable )
v Running a netstat -ban | findstr 8085 command from the VMware Virtual Center server shows many TCP/IP Ports are left open in a LAST_ACK state. Solution The behavior occurs because ephemeral ports, temporary ports that are used for client server communications, are not closed upon use. Ephemeral ports are limited to a range of ports and are only valid for the duration of the connection. In this case, on certain Microsoft Windows operating systems, certain connections leave the ports in a LAST_ACK state on the Virtual Center server. The range of ports can be exhausted after a time and when this situation happens, connectivity can fail until a port is freed. To prevent this event occurring, go to the Microsoft website at http://support.microsoft.com and search for KB979230. You can then download and install the fix.
WebLogic sensor
The WebLogic sensor discovers Oracle WebLogic Server application servers and WebLogic Server version information.
114
The JAR files of all releases of WebLogic 9 can be used to discover all releases of WebLogic 9 and 10.
Prerequisites
The WeblogicSensor sensor requires additional JAR files that are part of the Oracle WebLogic Server installation. You must copy these JAR files to the following directories on the TADDM server: v For Linux, Solaris, AIX, and Linux on System z operating systems: $COLLATION_HOME/lib/weblogic/9.0 $COLLATION_HOME/lib/weblogic/10.0 v For Windows operating systems: %COLLATION_HOME%\lib\weblogic\9.0 %COLLATION_HOME%\lib\weblogic\10.0 You must configure the specific name of the $COLLATION_HOME/lib/weblogic/ $VERSION_DIR directory in the $COLLATION_HOME/etc/discover-sensors/ WeblogicVersionSensor.xml file. There is no limit to the number of $VERSION_DIR directories that you can create in the $COLLATION_HOME/lib/weblogic/ directory. However, each directory must be configured in the WeblogicVersionSensor.xml file.
Security issues
The TADDM server requires the WebLogic system login name and the password that is used to log in to the WebLogic Product Console.
Limitations
TADDM does not support WebLogic discovery with the WebLogic sensor when using SSL. The WebLogic sensor must not be run with the WebLogic SSH pluggable sensors in the same discovery. Do not enable the WebLogic sensor and the WebLogic SSH pluggable sensors in the same discovery profile.
115
v v v v v v v v v v v v v v v v v v
app.j2ee.J2EEModule app.j2ee.J2EEResource app.j2ee.weblogic.WebLogicCluster app.j2ee.weblogic.WebLogicConnector app.j2ee.weblogic.WebLogicConnectorModule app.j2ee.weblogic.WebLogicDomain app.j2ee.weblogic.WebLogicEJBModule app.j2ee.weblogic.WebLogicJ2EEApplication app.j2ee.weblogic.WebLogicJDBCConnectionPool app.j2ee.weblogic.WebLogicJDBCDataSource app.j2ee.weblogic.WebLogicJDBCDriver app.j2ee.weblogic.WebLogicJDBCMultiPool app.j2ee.weblogic.WebLogicJDBCTxDataSource app.j2ee.weblogic.WebLogicJMSServer app.j2ee.weblogic.WebLogicJMSStore app.j2ee.weblogic.WebLogicJTA app.j2ee.weblogic.WebLogicMachine app.j2ee.weblogic.WebLogicSSLSettings
v app.web.WebVirtualHost
v $WEBLOGIC_HOME/server/lib/wlfullclient.jar
Make sure the user used to run TADDM has read access to the copied JAR files.
116
where X.X.X.X is the version number of the JarBuilder module in the WL_HOME/server/lib directory. For example:
java -jar ../../../modules/com.bea.core.jarbuilder_1.0.1.0.jar
3. Copy and bundle the wlfullclient.jar file with the client application. 4. Add the wlfullclient.jar file to your Java class path.
117
In the sample, the WeblogicServerVersionSensor sensor uses JAR files from the lib/weblogic/10.0 directory with JDK 1.5.0 and assumes that WebLogic Server 10.x is running.
You can use this configuration when the WebLogic server is using multiple interfaces on the Domain Admin Server. In this case, the value of DOMAIN_IP and DOMAIN_PORT is used instead of IP_OF_FIRST_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING and IP_OF_SECOND_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING.
118
In most cases, if you have the JAR files from the current version of WebLogic, you can also discover servers running older versions of WebLogic. When this method does not work, complete the following steps: 1. Run a discovery with the current set of JAR files. 2. Stop the TADDM server. 3. Copy the JAR files for the older or different version of the WebLogic server to the corresponding directories. 4. Start the TADDM server. 5. Run the discovery for the WebLogic server.
For example:
com.collation.agent.weblogic.domainsconfiguration= 9.158.143.20:7001-9.158.143.20:7002,9.158.143.50:7001;9.158.143.20: 7001-9.158.143.20:7002,9.158.143.50:7003
com.collation.agent.weblogic.protocols By default, this property is disabled, and the T3 protocol is used. If you uncomment this property, you can specify the list of protocols (separated by commas) to be used by the WebLogic sensors, as shown in the following example:
com.collation.agent.weblogic.protocols=t3,http
In this example, the T3 protocol is the first protocol that is tried. If this protocol fails, the HTTP protocol is used. If you want to use the HTTP protocol to connect to a WebLogic server instance, you must enable HTTP tunneling for that instance using the WebLogic Console.
Chapter 2. Application sensors
119
The only valid values are t3 and http. If you code an incorrect value, such as a value with typographical errors, the WebLogic server cannot process the request properly and might stop. com.collation.platform.os.ignoreLoopbackProcesses=true The default value is true, which means that the processes that are listening on loopback interfaces are ignored. Therefore, if a server is listening only on the loopback IP address (127.0.0.1), and not on any other externally available IP address, that server will not be discovered. This property controls the discovery of external IP addresses. If the value of this property is set to false, all processes with listening ports are considered for discovery. You must set this property to true if you want to discover an Oracle Application Server or the WebLogic sensors. For example, if the WeblogicServerVersionSensor sensor tries to start using a local host address, this property must be set to true.
120
Solution Ensure that you have the correct security authentication information. The TADDM server requires the WebLogic system login name and the password that is used to log in to the WebLogic Product Console.
Solution This message occurs when you are discovering a WebLogic Application Server. Although this situation is not a problem, ensure that the WebLogic sensor runs against the WebLogic Admin Server.
121
sensor that is configured in the XML file in the $COLLATION_HOME/etc/ discover-sensors directory. The following examples show how to code this property:
com.collation.discover.agent.WeblogicSensor2.timeout=7200000 com.collation.discover.agent.WeblogicSensor.timeout=7200000
Solution This sensor uses a protocol other than SSH for host access, the appropriate port needs to be open between the TADDM server and the target. In cases when a firewall prevents direct access from the discovery server to certain hosts or devices, you can specify a computer system that does have access to the hosts or devices to be an anchor host.
122
Security issues
The WebLogic pluggable sensors require computer system credentials or WebLogic credentials.
Limitations
For a discovery to run, the WebLogic pluggable sensors must have access to the domain configuration files. The location of the domain configuration directory can be determined by the sensor in the following specific situations: v The WebLogic server is started as a Windows service. v The WebLogic server is started as a Windows or UNIX process, and it is started with the following argument:
-Dpredefined.domain.config.dir=domain_directory
v The WebLogic server is started as a Windows or UNIX process, and it is started with the following argument:
-Dweblogic.RootDirectory=domain_directory
v The WebLogic server is started as a UNIX process, and the location of the domain configuration directory is set as one of the following process environment variables: DOMAIN_HOME LONG_DOMAIN_HOME PWD OLD_PWD OLDPWD v The WebLogic server is started as a Windows or UNIX process, and the process contains a variable with the path to the domains subdirectory. All domains are in the user_project_directory/domains/domain_name directory. A search for the configuration file is carried out in the directory and all sub directories defined in the path for the domains. For example, if a WebLogic process contains the variable -Dweblogic.system.BootIdentityFile=/home/weblogic/bea/my_user_projects/domains/ domain92/aaa/boot.properties, the following paths are searched for the config_file_name: /home/weblogic/bea/my_user_projects/domains/domain92/ /home/weblogic/bea/my_user_projects/domains/domain92/config/ v The WebLogic server is started as a Windows or UNIX process, and the process contains a variable with the path to the servers subdirectory. The servers
Chapter 2. Application sensors
123
directory is located in the Domain home directory. A search for the configuration file is carried out in the directory and all sub directories defined in the path for the servers. For example, if a WebLogic process contains the variable -Dweblogic.system.BootIdentityFile=/home/weblogic/bea/my_user_projects/domains/ domain92/servers/MS92_1/data/nodemanager/boot.properties, the following paths are searched for the config_file_name: /home/weblogic/bea/my_user_projects/domains/domain92/ /home/weblogic/bea/my_user_projects/domains/domain92/config/ v The WebLogic server is started as a Windows or UNIX process, and the process contains a variable with the path to the user_project subdirectory. The user_projects directory is the default directory containing WebLogic projects. A search for the configuration file is carried out in the directory and all sub directories defined in the path for the user_projects. For example, if a WebLogic process contains the variable -Dweblogic.system.BootIdentityFile=/home/weblogic/bea/my_user_projects/domains/ domain92/servers/MS92_1/data/nodemanager/boot.properties, the following paths are searched for the config_file_name: /home/weblogic/bea/user_projects/domains/domain92/ /home/weblogic/bea/user_projects/domains/domain92/config/ v The WebLogic launcher sensor configuration contains the following information: The domain configuration directory. The IP address on which the WebLogic administration console is listening. The port number on which the WebLogic administration console is listening. See the topic Configuring the sensor for details. On Windows, the WebLogic launcher sensor normally does not start if the WebLogic process is not started as a Windows service. It might start correctly if the required environment variables have been set up. On UNIX, when a non-typical installation has been performed, it might be necessary to set configuration information in the WebLogic launcher sensor configuration file. For the WebLogic managed server, the WebLogic process name must be called with the following argument:
-Dweblogic.management.server=server_name
The WebLogic SSH pluggable sensors must not be run with the WebLogic sensor in the same discovery, so you must not enable the WebLogic SSH pluggable sensors and the WebLogic sensor in the same discovery profile.
124
v v v v v v v v v v v v v v v v v v
app.j2ee.J2EEDomain app.j2ee.J2EEModule app.j2ee.J2EEResource app.j2ee.weblogic.WebLogicCluster app.j2ee.weblogic.WebLogicConnector app.j2ee.weblogic.WebLogicConnectorModule app.j2ee.weblogic.WebLogicDomain app.j2ee.weblogic.WebLogicEJBModule app.j2ee.weblogic.WebLogicJ2EEApplication app.j2ee.weblogic.WebLogicJDBCConnectionPool app.j2ee.weblogic.WebLogicJDBCDataSource app.j2ee.weblogic.WebLogicJDBCDriver app.j2ee.weblogic.WebLogicJDBCMultiPool app.j2ee.weblogic.WebLogicJDBCTxDataSource app.j2ee.weblogic.WebLogicJMSServer app.j2ee.weblogic.WebLogicJMSStore app.j2ee.weblogic.WebLogicJTA app.j2ee.weblogic.WebLogicMachine
v app.SoftwareContainer v app.web.WebVirtualHost
v Basic information about the structure of the WebLogic domain and servers.
Chapter 2. Application sensors
125
The WebLogic launcher sensor creates the following objects: v The WebLogic domain model object with only the attributes that are included in the naming rule. v The WebLogic server model objects with only the attributes that are included in the naming rule. The WebLogic launcher sensor starts the following sensors: v WebLogic domain sensor for administration server v WebLogic server sensor for administration server
v JMS server v Node manager settings The WebLogic domain sensor creates the WebLogic domain object.
126
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.
Limitations
The last modification dates of collected configuration files are not available. Application descriptor discovery is not supported.
127
<adminServer> Contains information about the IP address and port number on which the WebLogic administration console is listening. The following elements are used to specify this information: <listenAddress> The IP address on which the WebLogic administration console is listening. <listenPort> The port number on which the WebLogic administration console is listening. The following sample configuration file displays the typical usage of the <configuration> element, and its child elements:
<configuration className="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicLauncherConfigurationItem"> <domain> <item> <configDirectory>/opt/bea10/wl_10.0/domains/medrec/config</configDirectory> <adminServer> <listenAddress>127.0.0.1</listenAddress> <listenPort>7011</listenPort> </adminServer> </item> <item> <configDirectory>/opt/bea/user_projects2</configDirectory> <adminServer> <listenAddress>127.0.0.1</listenAddress> <listenPort>7002</listenPort> </adminServer> </item> </domain> </configuration>
You can also specify the location of the domain configuration directory by starting the WebLogic server with the following argument:
-Dpredefined.domain.config.dir=domain_directory
128
In the plugin.xml configuration file, you can configure the following elements: <discoverApplicationDetails> Specifies if the discovery of application/module details is enabled. The discovery of application/module descriptors (J2EE descriptors) can be time consuming because the descriptors are defined in additional configuration files on the remote machine where WebLogic is installed. The following sample configuration file displays the typical usage of the <discoverApplicationDetails> element:
<configuration className="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicApplicationConfigurationItem"> <discoverApplicationDetails>true</discoverApplicationDetails> </configuration>
The sensor fails with a Domain config dir not found error
Problem The Domain configuration directory cannot be found. Check the ps output for the process and verify in the limitations section that the configuration is supported. Solution Use one of the following methods: v Run the WebLogic server using the argument -Dpredefined.domain.config.dir=domain_directory or Dweblogic.RootDirectory=domain_directory v Configure the path to the domain administrator server in the WebLogic launcher sensor configuration. See the topic Configuring the sensor for details.
129
1. Set com.ibm.cdb.discover.WeblogicLauncherSensor.parseConfigXml=true in collation.properties. 2. Restart TADDM and run the discovery again. If extracting the server name from the command line fails, WeblogicLauncherSensor reads it from the local configuration file (config.xml).
130
Prerequisites
The sensor assumes the following prerequisites: v Discovery of the computer system must succeed. v DB2 must be installed in the instance owner's home directory.
Security issues
The DB2 user credentials must belong to the DB2 administration group. Discovery is performed by using shell scripts that run the following DB2 utility programs on the remote system: v dist/bin/db2find.sh v dist/bin/db2findschema.sh The scripts run the following DB2 commands: db2 db2ilist List instances command db2set DB2 profile registry command db2licm License management tool command db2level Show DB2 service level command db2 get dbm cfg Command line processor invocation command
Limitations
During discovery, the sensor temporarily changes the code page of the db2 command-line tool. The sensor reverts the code page to its original setting after the discovery is completed. Incorrect characters can be discovered if you are using a 32-bit DB2 on a 64-bit Windows operating system. This character encoding problem is due to a limitation of the 64-bit Windows operating system, which hides commands such as chcp from 32-bit applications such as the db2cmd.exe program.
Copyright IBM Corp. 2008, 2012
131
If more than one version of DB2 is installed on the same Windows computer system, the sensor cannot discover the IBM DB2 Universal Database (UDB) server. TADDM runs the topology building process on a periodic basis. Until the topology building process is complete after a discovery, the database names that are displayed for remote systems might not be unique. After the topology build process is complete, the database name contains both the port number and the IP address of the remote database.
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
132
133
For the following properties, you can also specify an IP address, as shown in the following example:
com.collation.discover.agent.DB2Agent.db2findscript.1.2.3.4=sudo
com.collation.discover.agent.DB2Agent.db2findscript=sudo This value enables access to the dist/bin/db2find.sh script executed during the discovery using the sudo command. com.collation.discover.agent.DB2Agent.db2findschemascript=sudo This value enables access to the db2findschema.sh script executed during the discovery using the sudo command. com.collation.discover.agent.DB2Agent.systemcommand=sudo This value enables access to the system command executed during the discovery using the sudo command.
Dependencies exist between a database and a business application but are not detected
Problem Although dependencies exist between a database and a business application, no dependency is detected because the user that is defined in the discovery access list for DB2 is not the instance owner. Solution For discovery processes to find the DB2 commands to list databases, the user that is defined in the discovery access list for DB2 must source the DB2 profile in the user profile.
134
Solution This error message appears because the secure copy (scp) command is not in the PATH of the user ID that is being used by the remote computer system to discover DB2. To correct this problem, edit or create a file called environment in <taddmusr>/.ssh on the remote computer system that is being discovered. Define the <taddmusr> PATH environment variable in this file. Make sure that you include the full path to the scp command in the PATH environment variable.
Solution This message is displayed because the PATH variable does not include the DB2 commands needed by the db2find.sh script.
Chapter 3. Database sensors
135
To correct this problem, add the required paths to the following entry in the collation.properties file:
com.collation.discover.agent.path.system_uname
Prerequisites
The IBM Informix JDBC driver must be installed on the IBM Informix Dynamic Server.
Limitations
The Informix Dynamic Server must be configured with the minimum requirement for discovery. Add the discovery service account to the group Informix on the Informix Dynamic Server.
136
v DefaultValue v EffectiveValue v OriginalValue app.db.ids.IDSDatabase v DatabaseLocale v LoggingType v Name app.db.ids.IDSInstance v BitSize v ConnectOption v Home v Host v Name v v v v v ProductName ProductVersion OnConfig Protocol SQLHostFile
v Status v VersionString app.db.ids.IDSSegment v OS_SHM_ADDR v OS_SHM_ID v OS_SHM_KEY v SegmentClass v Size app.db.ids.IDSServerProcess v OSProcessName v PID v VpClass v VpID app.db.ids.IDSSpace v Chunks v ObjectType v PageSize v SpaceName v SpaceNumber app.db.ids.IDSStartupEnvironmentVar v StartupEnvVarName v StartupEnvVarValue
137
To configure the access list, complete the following steps: 1. From the Discovery Management Console, create a discovery scope set that contains the IP address of the Informix Dynamic Server. 2. To create an access list, click the Access List icon. 3. In the Access List window, click Add. 4. In the Component Type field of the Access Details window, click ComputerSystem. 5. Type the credentials to access the target Informix Dynamic Server. TADDM uses JDBC to connect to the Dynamic Server.
Solution Ensure that the connection from the TADDM server to the Informix port on the database server is open.
Security issues
The SQL Server access list user must have the following minimal user/group role: db_datareader role. The role is required to access the following tables:
138
v v v v v
Ensure that the Local Administrators group has SQL access (part of the SQL authorization and configuration).
139
v Add the Windows user and password to the access list for the Windows computer system. v Add the SQL Server user to the access list for the SQL Server. To determine the type of authentication you need to use, verify with your SQL Server administrator which mode the SQL Server is running. Mixed mode supports both types of authentication.
140
If this property is not set, the sensor uses the default timeout specified in the com.collation.discover.DefaultAgentTimeout property.
v Grant the following access to the TADDM discovery user, which in the following example the user is taddmusr:
GRANT GRANT GRANT GRANT GRANT SELECT SELECT SELECT SELECT SELECT on on on on on sysdatabases to taddmusr; syscurconfigs to taddmusr; sysprocesses to taddmusr; sysobjects to taddmusr; syscolumns to taddmusr;
141
Oracle sensor
The Oracle sensor discovers Oracle Database servers.
Prerequisites
The following requirements must be met: v Discovery of the computer system must succeed. v Network connectivity between the TADDM server and the Oracle Listener must be functioning.
Security issues
The Oracle user credentials used to discover an Oracle database from TADDM, must have execute privileges. To ensure that the correct privileges are granted to the Oracle user, run the following command: grant execute on dbms_system to oracle_user; The Oracle database account requires CONNECT privileges. The Oracle access list user must have the following role: SELECT_CATALOG_ROLE. The role is required to read/query the following tables: v$version, global_name, v$parameter, dba_data_files, v$log, v$logfile, sys.dba_tables, v$bgprocess, v$process, v$controlfile, v$sga, v$sys_optimizer_env, dba_db_links, dba_tables, dba_views, dba_indexes, dba_sequences, dba_constraints, dba_source, dba_clusters, dba_db_links, dba_tablespaces, dba_synonyms, dba_mviews, dba_rollback_segs, dba_profiles, dba_roles, dba_users, dba_dimensions, dba_sys_privs, dba_role_privs, dba_tab_privs, and dba_ts_quotas.
142
3. Specify the following required information: v The operating system user name for the Oracle user v The operating system password for the Oracle user
Limitations
Some function that is provided by the Oracle sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. The following functions are not supported: v Application descriptor discovery v Oracle RAC discovery v Oracle ASM discovery v Raw schema discovery (the list of tables in the database is limited) v OracleDBLink model object discovery v OracleListener model object discovery
143
Parameters Parent Port RacDatabase SGAValues SID ServerProcesses OracleBackgroundProcess Description Name Pid OracleControlFile Name OracleDBLink IpAddress Port ServiceName OracleDataFile Name Size TableSpace OracleDatabase ControlFiles DBName DBVersion DataFiles InitValues Name RedoLogFiles SchemaRawData Schemas TableSpaces OracleInitValue Description Name Value OracleInstance BackgroundProcesses ConfigContents Database
144
Host KeyName Modules Name Port PrimarySAP ProcessPools ProductName ProductVersion SGAValues SID ServerProcesses Status OracleListener BindAddresses Name OracleModule FileName Name Schema OracleRAC Asm HomePath Name OCRLocation PrimaryNode RacDatabases VoteDiskPath OracleRedoLogFile Name Size OracleSGAValue Name Value OracleSchema Name Owner OracleServer ConfigFile Listeners
Chapter 3. Database sensors
145
OracleServerProcess Connections Name PID Ports OracleTableSpace Name Size ProcessPool Name RuntimeProcesses
146
WeblogicServerVersionSensor sensor tries to start using a local host address, this property must be set to true.
Sybase sensor
The Sybase sensor discovers Sybase Adaptive Server Enterprise (ASE) database servers.
Security issues
To assign the minimum privileges to the Sybase discovery user, run the following command:
grant select on sysengines from public
147
v v v v v v v v v v v v v v v v v
version master..sysconfigures master..sysusages master..syssegments master..sysprocesses master..sysengines master..sysdatabases master..sysdevices master..syscurconfigs master..sysservers master..syssrvroles master..syslogins master..sysloginroles master..syspartitions master..systhresholds master..sysresourcelimits master..systimeranges
Limitations
The Sybase sensor does not collect information about schemas owned by the dbo user.
148
v v v v v
v Value SybaseDatabase v Name v Options v v v v v v Owner Parent (SybaseServer) SchemasRawData Segments Tables Thresholds
v Users SybaseDevice v Description v FirstVirtualPageNumber v FixedPath v IsDefaultDisk v v v v v v v v v v v v v v IsDeviceMirrored IsDsyncEnabled IsDumpDevice IsMasterDeviceMirrored IsMirrorEnabled IsPhysicalDisk IsReadsMirrored IsSecondaryMirrorSideOnly IsSerialWrites IsSkipHeader LastVirtualPageNumber MirrorPath Parent (SybaseServer) RealFile
149
v v v v v v v v v v v
FailedLoginCount FullName IsAccountLocked IsPasswordExpired Language Name Parent(SybaseServer) PasswordDate SybaseRoles TotalCPUUsed TotalIOUsed
SybaseModule v Database v FileName v Name v Parent SybaseRemoteServer v IsMessageConfidential v IsMessageIntegrity v IsMutualAuthentication v IsNetworkPasswordEncrypted v v v v v v v v IsReadOnly IsRPCSecurityModelB IsTimeoutEnabled Name NetworkName RemoteNetworkCost RemoteServerClass SybaseServer
SybaseResourceLimitation v AppName v IsEnforcedDuringExecution v IsEnforcedPriorToExecution v v v v v v v v LimitationExceededAction LimitationScope LimitType LimitValue Login Name Parent (SybaseServer) TimeRange
150
v Parent v PasswordDate v Status SybaseSegment v Name v Parent v Size SybaseServer v BindAddresses v ConfigContents v ConfigFile v ConfigValues v Databases v v v v v Devices EngineProcesses FullVersion Home Host
v KeyName v Logins v Modules v v v v v v v v v v v Name PrimarySAP ProcessPools ProductName ProductVersion RemoteServers ResourceLimitations ServerProcesses Status SybaseRoles TimeRanges
SybaseServerProcess v Name v PID v Parent SybaseTable v CreationDate v Name v Parent(SybaseDatabase) v Partitions SybaseTablePartition v FirstPage v NumPages
Chapter 3. Database sensors
151
v Parent (SybaseTable) v PartitionID SybaseThreshold v IsLastChance v Name v Parent (SybaseDatabase) v Segment v ThresholdExeededProcedure v ThresholdSize v User SybaseTimeRange v EndDay v EndTime v v v v Name Parent (SybaseServer) StartDay StartTime
Sybase IQ sensor
The Sybase IQ sensor discovers Sybase IQ database servers.
Security issues
To assign the minimum privileges to the Sybase discovery user, run the following command:
grant execute on sp_iqdbsize
152
153
154
Anchor sensor
The Anchor sensor is used for discovery behind a firewall.
Prerequisites
All software components that are needed for discovery from the remote anchor are automatically deployed to the anchor during the discovery process. To exchange data, you must use the Secure Shell (SSH) version 2 protocol.
155
change the default to false, anchors are deployed only if any IP address from the scope cannot be pinged, or if port 22 cannot be reached on any of the discovered IP addresses. com.collation.discover.anchor.lazyDeployment=false Specifies if files must be copied during anchor deployment, or when the sensor requiring the files is going to be launched. In both cases only different files are copied. Valid values are true and false. The default is false. The following example provides some insight to how this property affects TADDM functionality: The WebSphere Application Server sensor has dependencies in the dist/lib/websphere directory which are 130 MB in size. If the flag is set to false, this data is copied to the target host when the anchor is deployed. If the flag is set to true, the data is copied when the WebSphere Application Server sensor is about to be run on the anchor. If no WebSphere Application Server sensor is run through the anchor, 130 MB is not sent to the remote host. com.collation.discover.anchor.connectType=ssh Specifies whether to connect to the anchor using a ssh tunnel or a direct socket. Valid values are ssh and direct. The default is ssh. To specify the connection type for a particular address, use com.collation.discover.anchor.connectType.1.2.3.4=ssh, where 1.2.3.4 is the address for which you want to specify the connection type. com.collation.platform.session.GatewayForceSsh Specifies whether to force the gateway to act independently of the anchor. Valid values are true and false. Set the value to true to resolve Cygwin issues when both the gateway and anchor are on the same system. When the value is set to true, an SSH session is used to transfer traffic between the gateway and anchor rather than a local session.
156
Prerequisites
In a discovery profile, if you are using the asynchronous discovery ping sensor, you must disable the ping sensor because you cannot enable both of these sensors in a discovery profile.
Prerequisites
To discover configuration files, the sensor requires that the cksum program and associated libraries are installed on the target operating system.
Limitations
See the limitations for the generic server sensor.
157
v app.web.WebServer The following model objects are used to extend TADDM application sensors: v v v v v v v v app.db.db2.Db2Server app.db.mssql.SqlServer app.j2ee.jboss.JBossServer app.j2ee.weblogic.WebLogicServer app.j2ee.websphere.WebSphereServer app.messaging.exchange.ExchangeServer app.messaging.mq.MQQueueManager app.sms.SMSiteServer
Limitations
See the limitations for the SNMP MIB2 sensor.
158
Limitations
A sensor that requires credentials and a generic custom sensor can both discover the same target system during multiple discoveries. Depending on the nature of the data discovered without credentials, the system cannot guarantee that objects that are created by the custom server template are reconciled with sensor-created artifacts.
159
Limitations
Some function that is provided by the generic server sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. On Solaris operating systems that support virtualization, from the global zone, the generic server sensor does not support the discovery of runtime processes in local zones.
where mynetstat.txt contains the output of the netstat -nao command, and the type command is used to print the contents of the file.
160
Prerequisites
For the sensor to discover a target system, the target system must have the following commands installed in the default location for the respective operating system: v v v v compress command netstat command sadc command sar command
On target systems that are running the following operating systems, the following respective prerequisites must be met: v Linux The compress command must be available. The netstat command must be available. The sar command must be available. The sadc command must be available. v Solaris The compress command must be available. The netstat command must be available. The sar command must be available. v AIX The compress command must be available. The netstat command must be available. The sar command must be available. To run the sar command, the TADDM service account must be part of the adm group. v HP-UX The compress command must be available. The netstat command must be available. The sar command must be available. To schedule cron and at jobs, the TADDM service account must be added to the cron.allow and at.allow files.
Limitations
The sensor is intended for short-term use (for example, a maximum of one month of use) to analyze servers and identify consolidation targets. The sensor can be used only for the firewall zone in which the TADDM server resides. The use of an anchor server is not supported. Over a longer period of time, for determining server availability, performance, and utilization, or for discovering applications that span firewall zones, use the IBM Tivoli Monitoring product.
161
Specify the time interval and duration for collecting data. Before starting to collect data, you must wait until after the time interval has elapsed. 4. Periodically collect data by running the taddmasd/scriptsRunner.sh script. This script generates an archive file that contains the utilization data. 5. Move the resulting archive file to the TADDM server. 6. Create a new asynchronous discovery profile for the Utilization sensor, enable the sensor, and run an asynchronous discovery. 7. When the collection of utilization data is complete, to stop the Utilization sensor, change to the taddmasd/ com.ibm.cdb.discover.sensor.sys.utilization_7.2.0 directory, and run the following command:
./utilizationDeployer.sh -u
See the TADDM Administrator's Guide for information about configuring for script-based discovery.
162
net.IpInterface v IpAddress relation.Gauges v Source (OperatingSystemMetric) v Target (OperatingSystem) The following computer system types are discovered: sys.aix.AixUnitaryComputerSystem sys.hpux.HpUxUnitaryComputerSystem sys.linux.LinuxUnitaryComputerSystem sys.sun.SunSPARCUnitaryComputerSystem sys.windows.WindowsComputerSystem The following attribute is associated with these model objects: v signature The following operating system types are discovered: sys.aix.Aix sys.hpux.HpUx sys.linux.Linux sys.sun.Solaris sys.windows.WindowsOperatingSystem The following attribute is associated with these model objects: v OSName
163
Table 8. Configuration parameters Parameter name operatingMode Description The mode of operation for the sensor. The following values are valid: ONCE Specifies that the collection scripts run once for the interval and numDays, or maxFileSize, specified, whichever comes first. When the collection scripts have finished, the data is collected by the sensor the next time that it runs. The data collected is parsed and stored on the TADDM database. All output files on the target machine are cleaned up.
RESTART Specifies that when the collection scripts finish as normal, the collection scripts are started again. CLEANUP Specifies that any collection currently running on the system is immediately stopped and cleaned up. Once a cleanup operation is called, collection can only be restarted on this machine by setting the operatingMode value to RESTART. collectionMode The mode of collection for the sensor. The following values are valid: ALWAYS Specifies that data is collected each time the sensor is run on the target system, regardless of whether the collection scripts have completed or not. END Specifies that data is collected when the sensor is run on the target system, only if the collection scripts have completed. Except in situations where operatingMode is set to CLEANUP, any discovery performed before the collection scripts have completed results in no data collection.
The collection interval, in minutes, for collection scripts running on the target. Valid values are between 3 minutes and 60 minutes. The number of days that the collection scripts run on the target. Valid values are between 1 day and 35 days. The maximum size, in MB, for the output files created by the collection scripts. Valid values are between 1 MB and 100 MB.
164
3. Remove the IBM Tivoli Utilization sensor lock file. To perform a manual cleanup on a Windows target machine, complete the following steps: 1. Navigate to the C:\ directory. 2. Remove the WINTEL-MAN-PERF.VBS script. 3. Remove the PerformanceData_hostname.out file. 4. Remove the IBM Tivoli Utilization sensor lock file.
Procedure
To configure the Utilization BIRT report complete the following steps in the Data Management Portal: 1. Click Analytics > BIRT Reports. The TADDM BIRT Reports window is displayed. 2. Select TADDM_SERVER_UTILIZATION report and click Run Report. 3. In the Parameter window, a value for each of the following parameters must be specified: Scope From the list of available TADDM scopes, select a scope. Metric From the list of available metrics, select the metric for which you want to view data, or select ALL to display data for all metrics. Operator Operators are used to restrict the data displayed in the report. From the list of available operators, select an operator, or select N/A to display all data for the selected metric. Value If you specified an operator, you must specify a corresponding value. Otherwise, select N/A to display all data for the selected metric. Another value If you specified an operator, and it requires two values, you must specify a corresponding value for the second value. Otherwise, select N/A to display all data for the selected metric. Number of application dependencies The number of application dependencies is used to restrict the data displayed in the report. Specify the number of application dependencies, or select N/A to display all data for the selected metric. 4. Click OK. The report output is displayed in the BIRT Report Viewer.
165
What to do next
To configure the Hourly Peak Server Utilization BIRT report complete the following steps in the Data Management Portal: 1. Click Analytics > BIRT Reports. The TADDM BIRT Reports window is displayed. 2. Select TADDM_SERVER_UTILIZATION_HOURLY_PEAK report and click Run Report. 3. In the Parameter window, a value for each of the following parameters must be specified: Scope From the list of available TADDM scopes, select a scope. Date From the list of available dates, select a date. 4. Click OK. The report output is displayed in the BIRT Report Viewer.
166
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.
Metrics data not discovered from a target machine when running an asynchronous discovery
Problem An asynchronous discovery is run, but the IBM Tivoli Utilization sensor does not discover metrics data on the Solaris operating system. Solution You must start the IBM Tivoli Utilization sensor from the extracted script package on the target system.
IP device sensor
The IP device sensor creates a lightweight computer system that represents an IP device on the network.
167
IP interface sensor
The IP interface sensor discovers IP interfaces.
Limitations
For IPv6 and IPv4 Router Details, the IP forwarding attribute is set to false regardless of the setting on the discovered Windows system. Do not enable the IP interface sensor. The function that the IP interface sensor provides is now provided by the appropriate computer system sensor. Enabling the IP interface sensor can cause performance issues.
Ping sensor
The ping sensor discovers reachable IP addresses. It gathers information from devices and systems that support TCP/IP.
If you want the ping sensor to use only port 161, add the property with the following value:
168
com.collation.pingagent.ports=161
Ping sensor discovery ends with an unable to establish loopback connection message
Problem The sensor fails when the scope of discovery is large, due to a timeout error and the following message displays:
Unable to establish loopback connection
View the log file for a detailed description of the message, for example:
<log start> java.io.IOException: Unable to establish loopback connection at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:172) at java.security.AccessController.doPrivileged(AccessController.java:246) at sun.nio.ch.PipeImpl.<init>(PipeImpl.java:188) at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:45) at java.nio.channels.Pipe.open(Pipe.java:148) at sun.nio.ch.WindowsSelectorImpl.<init>(WindowsSelectorImpl.java:192) at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:53) at java.nio.channels.Selector.open(Selector.java:224) at com.collation.platform.session.Ping$Connector.<init>(Ping.java:303) at com.collation.platform.session.Ping.pingArray(Ping.java:656) at com.collation.platform.session.Ping.pingLoop(Ping.java:574) at com.collation.platform.session.Ping.ping(Ping.java:557) at com.ibm.cdb.discover.sensor.net.ping.PingSensor.do_ping(PingSensor.java:75) at com.ibm.cdb.discover.sensor.net.ping.PingSensor.discover(PingSensor.java:92) at com.collation.discover.engine.AgentRunner.run(AgentRunner.java:214) at com.collation.discover.engine.DiscoverEngine.processWorkItem(DiscoverEngine.java:1184) at com.collation.discover.engine.DiscoverEngine$DiscoverWorker.run(DiscoverEngine.java:867) Caused by: java.nio.channels.ClosedByInterruptException at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:216) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:543) at java.nio.channels.SocketChannel.open(SocketChannel.java:161) at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:120) ... 16 more <log end>
Solution Use one of the following methods to resolve the problems: v Perform the discovery on a smaller scope. v In the collation.properties file, increase the timeout value for a longer discover time for the following property:
com.collation.discover.agent.PingSensor.timeout=600000
Port sensor
The port sensor discovers open ports on a host system. You can change certain aspects of the port sensor using the sensor configuration file. You must create a custom discovery profile to change the port sensor configuration. Before changing the configuration file, contact IBM Software Support.
169
Session sensor
The session sensor creates a session between the TADDM server and the target computer system. Typically, the session is either a Secure Shell (SSH) session or a Windows Management Instrumentation (WMI) session.
Prerequisites
The sensor requires the following software: v Nmap tool. See Configuring Nmap on page 171 for details. v WinPcap tool for Windows operating systems. Although this tool is available on the TADDM DVD, you must install it manually because it is not installed during the TADDM installation. v Sudo tool for non-Windows operating systems. For TADDM on AIX operating systems: For the TADDM user to use the nmap tool through sudo, you must install and configure sudo version 1.6.7p5. This is because TADDM has problems with the most recent sudo version, which is version 1.6.9p15.
Security issues
To configure sudo access for the TADDM user, you need to set a nopasswd option in the /etc/sudoers file for the TADDM user.
Limitations
Firewalls between targeted scopes and the TADDM server or remote anchors can severely degrade Stack Scan reliability and performance. In this situation, use remote anchors behind the firewall to improve performance. The version of the operating system might not be discovered properly depending on what the Stack Scan sensor receives from Nmap. For example, Windows Server 2008 is classified as Windows Vista, AIX 6.x as AIX 5.x, Linux for System z as Other Computer System. The discovery of computer systems running the Tru64 UNIX operating system is not supported by Nmap. Use the following command to check the operating system version returned by Nmap:
170
-oX - IPaddress
Application servers and services discovered using a credential-less (Level 1) discovery are reconciled with the application servers and services using a Level 2 or Level 3 discovery, only if the binding TCP ports are the same. All application servers and services discovered using a Level 1 discovery remain following a Level 2 or Level 3 discovery, but applications and services matching on the binding ports are merged.
v sys.zOS.ZOS v sys.zOS.ZSeriesComputerSystem
Configuring Nmap
The Stack Scan sensor uses Nmap to gather data about the targets for credential-less discovery.
Installing Nmap
Before installing Nmap for any operating system, see the TADDM support site at http://www.ibm.com/software/sysmgmt/products/support/ IBMTivoliApplicationDependencyDiscoveryManager.html for recent news about your specific operating system and Nmap versions. Nmap is not installed during the TADDM installation. The Nmap tool is available on TADDM DVD #2, and you must install it manually. Install Nmap on the TADDM server and all anchor servers. For more information, see the readme file in the Nmap directory on the DVD.
Chapter 4. Generic sensors
171
where v TADDM_userid is the user ID that starts the TADDM server, or the discovery service account on an anchor. If the sudoers file contains a Defaults requiretty line, comment it out or delete the line. When the Stack Scan sensor is running with Nmap, the TADDM server user ID can be given root execution permission only for the Nmap command. Add the following line in the /etc/sudoers configuration file:
TADDM_userid ALL=(ALL) NOPASSWD:nmap_path
where v TADDM_userid is the user ID that starts the TADDM server, or the discovery service account on an anchor. v nmap_path is the full path to the location of the nmap command. If the sudoers file contains a Defaults requiretty line, comment it out or delete the line.
172
v The user ID that starts the discovery service account on the anchor server. 2. Run the following command:
sudo nmap -T Normal -O -sS -oX - IPaddress/32
where v IPaddress is a valid host system that is up and running on your network. The output produces an XML document that shows the ports and operating systems on that computer system.
Limitation
Because of a limitation on AIX, only four active Nmap commands can be run at the same instance. To ensure that this limit of Nmap commands is not exceeded, complete the following steps: 1. Create a discovery profile. 2. In the new discovery profile, create a StackScanSensor configuration, and enable the configuration. 3. Set the values of the following properties to 1: v nmapMaxOsScanTreads v nmapMaxPingScanTreads 4. To save the configuration, click OK. 5. To save the discovery profile, click Save. Use this discovery profile for StackScan discoveries. 6. If the number of computer systems in the scope being discovered exceeds 2048, set the following property in the collation.properties file:
com.collation.discover.dwcount=4
173
The Stack Scan sensor uses the following entries in the collation.properties file: com.collation.sudoCommand=sudo This value specifies the sudo location. com.collation.discover.agent.StackScanSensor.timeout=7200000 This value specifies the time interval in milliseconds before a timeout occurs during a discovery.
The Stack Scan sensor completes successfully, but no Computer Systems are stored
Problem Doing a Level 1 discovery, the Stack Scan sensor finishes without errors, but it does not store any computer system information. In the services/DiscoveryManager.log, you see the following message:
2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])] WARN cdb.STDERR - Mar 26, 2008 11:05:26 AM invocation failed: sudo: sorry, you must have a tty to run sudo From the TADDM server command line you can successfully do an su - <run as user> and then sudo "nmap -0 10.1.2.3
Solution For non-windows platforms, give root authority for all commands to the TADDM user ID that starts the TADDM server. In addition, if you are using a TADDM anchor server, give root authority to the discovery service account on the anchor server. See Configuring Nmap on page 171 for details.
The Stack Scan sensor does not discover Computer Systems on a Linux system
Problem On a Linux server, when performing a Level 1 discovery, the Stack Scan sensor completes successfully, however, there are no Computer Systems stored. In the services/DiscoveryManager.log, the following message can be seen:
2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])] WARN cdb.STDERR - Mar 26, 2008 11:05:26 AM invocation failed: sudo: sorry, you must have a tty to run sudo
You see this error even though the sudo command works successfully for the run_as user from the command line. Solution Complete the following steps: 1. Type the OS command visudo to edit the /etc/sudoers file 2. Once the file opens, comment out the line Defaults requiretty. 3. Save and close the file.
174
The network configuration on Linux for System z systems does not create packets that Nmap can read
Linux for System z supports both OSA and VSWICH network interfaces operating in Layer 3 (Network Layer) or Layer 2 (Link Layer) mode. If operating in Layer 2 mode, TCP packets contain a valid ethernet Link Layer header required by Nmap. However, systems using OSA or VSWITCH operating in Layer 3 mode require adding the QETH_OPTIONS=fake_ll=1 to the hardware configuration file for the interface. The following section describes how to modify the hardware configuration file enabling Nmap to operate with Layer 3 network interfaces. For more information about OSA and VSWITCH and their operating modes, see Chapter 7 qeth device driver for OSA-Express (QDIO) and HiperSockets in the Linux on System z Device Drivers, Features, and Commands at: http:// download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/ lk31dd03.pdf. Problem The network configuration on Linux for System z systems does not create packets that Nmap can read. The Stack Scan sensor uses Nmap to gather data about the targets for credential-less discovery. If Nmap is not working properly, the Stack Scan sensor does not store any computer systems. Although the sensor runs without errors, the Linux for System z system that is running the Stack Scan sensor returns the following message:
stored - 0 ComputerSystems in the database
If you type the nmap <hostname> command for any system other than the local host, the following message is displayed:
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0...
Solution Depending on your operating system, perform the following actions: On SUSE Linux for System z systems The network must run with the following option:
QETH_OPTIONS=fake_ll=1
Add this option to the configuration file for the NIC. Depending on the NIC that is used, the name of the file changes. Contact your system administrator for the name of the configuration file that your system uses. The configuration file must be in the /etc/sysconfig/hardware directory. The file name might be hwcfg-qeth-bus-ccw-0.0.5000. On RedHat Linux for System z systems The network must run with the following option:
OPTIONS=fake_ll=1
Add this option to the configuration file for the NIC. Depending on the NIC that is used, the name of the file changes. Contact your system administrator for the name of the configuration file that your system uses.
175
The configuration file must be in the /etc/sysconfig/networkscripts directory. The file name might be ifcfg-eth0. Verify that the alias in the /etc/modprobe.conf file includes the following information:
alias eth0 qeth
Stack Scan sensor fails with a message: sudo: sorry, you must have a tty to run sudo
Problem During a discovery, if the Discovery Management Console where the TADDM server was started is closed, the sensor fails. The message: sudo:sorry, you must have a tty to run sudo is displayed. If you start the Discovery Management Console and leave it open the sensor works. Solution Comment out or delete the Defaults requiretty line from the /etc/sudoers configuration file on the TADDM server.
176
Solution This problem occurs when the system is configured not to allow the root user to run the sudo command. To fix the problem, edit the collation.properties file and set the com.ibm.cdb.discover.sensor.idd.stackscan.alwaysUseLocalAnchor property to true. Then restart the TADDM server.
The Stack Scan sensor does not discover Computer Systems on an AIX system
Problem On an AIX server, when performing a Level 1 discovery, the Stack Scan sensor completes successfully, however, there are no Computer Systems stored. In the services/DiscoveryManager.log, the following message can be seen:
2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])] DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223] )] DEBUG stackscan.ExecCmd - standard err:/taddm/cmdb/dist/nmap/nmap-4. 76/nmap[25]: 708778 Segmentation fault(coredump)
In the Nmap folder a core file is created during the discovery. Solution Create a discovery profile or edit an existing profile for the Stack Scan sensor. In the Configuration section of the Create Configuration window, click nmapExec. Then double-click the Value field in the row, and append -d to the value nmap. For example, the new value is nmap -d.
177
178
179
PingSensor
PortSensor
SnmpLightSensor
No
Yes
SessionSensor
No
Connection made
SnmpMib2Sensor
Figure 1. Calling sequence for SNMP Light sensor and SNMP MIB2 sensor
SnmpMib2Sensor SnmpLightSensor
Is Cisco device?
Yes
Yes
Is FC switch?
No
CustomMib2ComputerSystemSensor
CiscoPortSensor
CiscoVlanSensor
FCSwitchSensor
EntityMIBSensor
BridgeSnmpSensor
Figure 2. Calling sequence for SNMP sensors, starting after the SNMP Light sensor or the SNMP MIB2 sensor is called
You can then compare entries in the log file output with direct SNMP queries you run against the devices using snmpwalk. You can download SNMP query tools that support snmpwalk from http://www.net-snmp.org/download.html. If SNMP V3 authentication is used with encryption, you must also download OpenSSL from http://www.slproweb.com/products/win32openssl.html. The following example shows identical queries, with the first using V3 authentication (although the keys have been removed) and the second using community string authentication:
180
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
181
Procedure
1. In the Discovery Management Console, click Discovery > Computer Systems. 2. In the Computer Systems view, click Add. The Computer System Details window opens. 3. In the Name field, type Foundry Switch. 4. In the Action field, select Discover. 5. Select Enabled. 6. Optional: In the Icon field, click Browse to choose an icon for the device. This icon is used only to distinguish the template in the Computer Systems view. (The icon is not used during or after discovery.) 7. Select MIB. 8. In the Identifying Criteria field, select Any Criteria. 9. For the first criterion, specify the following values:
Sys OID is .1.3.6.1.4.1.1991.1.3.34.2.1.1.1
Then click Add Criterion. 10. For the second criterion, specify the following values:
Sys OID starts-with .1.3.6.1.4.1.1991.1.3.36
Then click Add Criterion. 11. For the third criterion, specify the following values:
Sys OID starts-with .1.3.6.1.4.1.1991.1.3.40
Then click Add Criterion. 12. Click OK. The new template is added to the end of the list. 13. To add an action class file for the template, create a file named Foundry Switch.xml in the $COLLATION_HOME/etc/templates/action directory. Add the following content to the file:
<?xml version="1.0" encoding="UTF-8"?> <results xmlns="urn:www-collation-com:1.0" xmlns:coll="urn:www-collation-com:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:www-collation-com:1.0 urn:www-collation-com:1.0/results.xsd"> <UnitaryComputerSystem array="1" xsi:type= "coll:com.collation.platform.model.topology.sys.UnitaryComputerSystem"> <type>Bridge</type> <manufacturer>Foundry Networks</manufacturer> </UnitaryComputerSystem> </results>
This XML file specifies that all discovered SNMP computer system devices matching the Foundry Switch template use the com.collation.platform.model.topology.sys.UnitaryComputerSystem model class, have the type attribute set to Bridge and the manufacturer attribute set to Foundry Networks. Note: The name of the action class file (without the .xml extension) must match the name of the SNMP computer system template.
182
What to do next
The new template can be used immediately (you do not need to restart the TADDM server).
Procedure
1. In the Discovery Management Console, click Discovery > Computer Systems. 2. In the Computer Systems view, click Add. The Computer System Details window opens. 3. In the Name field, type Foundry Router. 4. In the Action field, select Discover. 5. Select Enabled. 6. Optional: In the Icon field, click Browse to choose an icon for the device. This icon is used to distinguish the template in the Computer Systems view. (The icon is not used during or after discovery.) 7. Select MIB. 8. In the Identifying Criteria field, select Any Criteria. 9. For the first criterion, specify the following values:
Sys OID is .1.3.6.1.4.1.1991.1.3.34.2.1.1.2
Then click Add Criterion. 10. For the second criterion, specify the following values:
Sys OID starts-with .1.3.6.1.4.1.1991.1.3.44
Then click Add Criterion. 11. Click OK. The new template is added to the end of the list. 12. To add an action class file for the template, create a file named Foundry Router.xml in the $COLLATION_HOME/etc/templates/action directory. Add the following content to the file:
<?xml version="1.0" encoding="UTF-8"?> <results xmlns="urn:www-collation-com:1.0" xmlns:coll="urn:www-collation-com:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:www-collation-com:1.0 urn:www-collation-com:1.0/results.xsd"> <UnitaryComputerSystem array="1" xsi:type= "coll:com.collation.platform.model.topology.sys.UnitaryComputerSystem"> <type>Router</type> <manufacturer>Foundry Networks</manufacturer> </UnitaryComputerSystem> </results>
This XML file specifies that all discovered SNMP computer system devices matching the Foundry Router template use the com.collation.platform.model.topology.sys.UnitaryComputerSystem model class, have the type attribute set to Router and the manufacturer attribute set to Foundry Networks.
183
Note: The name of the action class file (without the .xml extension) must match the name of the SNMP computer system template.
What to do next
The new template can be used immediately (you do not need to restart the TADDM server).
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
184
185
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
186
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
187
You can do this using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
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)
188
v v v v v
Pool member table: 1.3.6.1.4.1.3375.2.2.5.3.2 Pool table: 1.3.6.1.4.1.3375.2.2.5.1.2 Virtual Server table: 1.3.6.1.4.1.3375.2.2.10.1.2 Virtual Server Pool table: 1.3.6.1.4.1.3375.2.2.10.6.2 Virtual Server Rule table: 1.3.6.1.4.1.3375.2.2.10.8.2
v Virtual Address table: 1.3.6.1.4.1.3375.2.2.10.10.2 F5 BIG-IP version 10: v Pool member table: 1.3.6.1.4.1.3375.2.2.5.3.2 v Pool table: 1.3.6.1.4.1.3375.2.2.5.1.2 v Virtual Server table: 1.3.6.1.4.1.3375.2.2.10.1.2 v Virtual Server Rule table: 1.3.6.1.4.1.3375.2.2.10.8.2 v Virtual Address table: 1.3.6.1.4.1.3375.2.2.10.10.2
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
189
The SnmpMib2Sensor invokes the BigIPVlanSensor. A VlanInterface model object is created for each VLAN in the VLAN map (for example, the interface through which known VLANs can be addressed). This allows L2 topology views to be built.
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
190
The SNMP MIB2 sensor invokes the Bridge SNMP sensor. The Bridge SNMP sensor gathers the MAC address data of attached devices (specifically, the interface number through which known MAC-addressed devices can be reached), which is needed to build the Level 2 topology views. The sensor follows the standards documented in RFC 1286 to retrieve some of the MAC Forwarding Database (fdb) table entries. The following OIDs are queried: v .1.3.6.1.2.1.17.4.3.1.1 v .1.3.6.1.2.1.17.4.3.1.2 OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses, as shown in the following example. These OIDs are then queried to determine the interface through which the MAC device can be accessed.
snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1 .1.3.6.1.2.1.17.4.3.1.1 SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.42.208.0 = Hex-STRING: 00 12 F2 2A D0 00 SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.50.0.0 = Hex-STRING: 00 12 F2 32 00 00 SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.51.88.0 = Hex-STRING: 00 12 F2 33 58 00 SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.218.128.177 = Hex-STRING: 00 12 F2 DA 80 B1 SNMPv2-SMI::mib-2.17.4.3.1.1.0.208.4.45.228.10 = Hex-STRING: 00 D0 04 2D E4 0A snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1 .1.3.6.1.2.1.17.4.3.1.1.0.18.242.42.208.0 SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.42.208.0 = Hex-STRING: 00 12 F2 2A D0 00 snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1 .1.3.6.1.2.1.17.4.3.1.2.0.18.242.42.208.0 SNMPv2-SMI::mib-2.17.4.3.1.2.0.18.242.42.208.0 = INTEGER: 282
The Bridge SNMP sensor also provides specific details about the Computer System L2 Interfaces that are attached to the switch. The SNMP MIB2 sensor provides generic information about the existence of the device interfaces, and the Bridge SNMP sensor provides detailed information about the MAC addresses that are accessible through the device interfaces. For example, Table 10 shows the names of MAC devices that have been discovered by the Bridge SNMP sensor. TADDM can determine the names because the computer system that owns that MAC device has been discovered. If the name of the device is unknown, the MAC address is used.
Table 10. Level 2 bridge topology data Name ethernet 1/9 ethernet 1/10 ethernet 1/11 ethernet 1/12 ethernet 10/2 Computer System L2 Interfaces NC84CDRS1LDPC02 00040DFDE53 NC84CDRS1LDPC04 NC84CDRS1LDPC03 000CDBF90C19
The sensor also follows the standards that are documented in RFC 1286 to retrieve some of the port table information. The following OIDs are queried: v .1.3.6.1.2.1.17.1.4.1.1 v .1.3.6.1.2.1.17.1.4.1.2
191
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
192
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
193
Prerequisites
You must have the following access: v SSH access that can run lsof v Read permission to the $CPMDIR/conf/objects.C directory on the system where the Check Point FireWall-1 is running v Execute permission for the $CPMDIR/bin/fw command v Read permission to the $CPMDIR/conf/*.W files, which contain the editable versions of the rule sets The CPMDIR environment variable must be set for the TADDM user.
Unable to retrieve information from the Check Point server host machine
Problem The Check Point sensor fails during discovery. Solution Verify that you have the following permissions: v Read permission to the $CPMDIR/conf/objects.C directory on the system where the Check Point FireWall-1 is running v Execute permission for the $CPMDIR/bin/fw command v Read permission to the $CPMDIR/conf/*.W files, which contain the editable versions of the rule sets
Prerequisites
The system object ID (sysObjectID) must return one of the following OIDs: v OID = .1.3.6.1.4.1.1919. v OID = .1.3.6.1.4.1.2620.
194
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.
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
Limitations
In TADDM Change History reports, the Cisco ASA device is displayed as a PIX device.
195
com.collation.CiscoExpectTimeout=60000 Increase the CiscoExpectTimeout value (in milliseconds) if the target system is available and running, but the following error is displayed:
The ssh login did not work correctly
196
The CdpSensor discovers cdpCacheDeviceId and cdpCacheDevicePort information and builds the local interface for the peer devices which is used to build the segment.
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console. v For TADDM to run a complete discovery, SNMP and Telnet must be enabled. You must configure Telnet access with a user name and password, and you must enable the password.
197
After TADDM completes the discovery, the sensor name appears in the GUI, but the Config files tab does not appear as expected
Problem Telnet access is not configured correctly. Solution Configure Telnet access with a user name and password, and make sure that the password is enabled.
198
1. Select CiscoDeviceAuth as the Component Type. 2. Specify the access information (user name, password, and enable password) that TADDM must use for authentication to the target computer system. Leave the enable password blank if not required. 3. If your Cisco IOS sensor is using a Telnet protocol and does not prompt for a user name, type default in the user name field.
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console. v For TADDM to run a complete discovery, SNMP and Telnet must be enabled. You must configure Telnet access with a user name and password, and you must enable the password.
Chapter 5. Network sensors
199
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
200
v For TADDM to run a complete discovery, SNMP and Telnet must be enabled. You must configure Telnet access with a user name and password, and you must enable the password.
CiscoWorks sensor
The CiscoWorks sensor collects data from CiscoWorks servers. The sensor works by invoking the RME servlet.
201
v Type
The sensor also gathers .1.3.6.1.2.1.55.1.1.0., which contains IPv6 information according to RFC 2466. OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses. These OIDs are then queried to determine the interface through which the MAC device can be accessed. If the SNMP MIB2 sensor also runs, additional information is gathered and shown in the Router Details, Bridge Details, IP, and Ports tabs.
202
v v v v
The sensor queries OID .1.3.6.1.2.1.55.1.1.0. which contains the IPV6 information per RFC 2466. The sensor also queries OID .3.6.1.2.1.17.4.3.1.1. which returns a list containing OIDs for known MAC addresses. These OIDs are then queried to get the interface through which the MAC device can be accessed.
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
203
The SnmpMib2Sensor invokes the ExtremeVlanSensor when VLANs are configured for the device.
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
204
Limitations
The following limitations apply: v The sensor cannot discover a BladeCenter chassis if the Management Module is not responsive. v The sensor cannot discover BladeCenters that have two configured network interfaces (eth0 and eth1). v You cannot start the first BladeCenter discovery against an empty database. Computer system sensors that discover operating systems running on blades (such as Linux and Windows) must be run first. This limitation applies only to the first BladeCenter discovery. v The sensor might not obtain sufficient Vital Product Data (VPD) against Redundant Management Modules to create certain model objects. Instances of the ComputerSystem and BladeCenterManagementModule classes representing Redundant Management Modules, for example, might not be created. In this case, instances of the Board class represent the module. v After discovering one or more BladeCenters using the BladeCenter sensor, the components BladeCenter and BladeCenter Management Module are not present in the list of component types available for use with custom queries. Therefore you cannot run a custom query for these types of components. This issue applies only to the TADDM Data Management Portal and not to the Discovery Management Console. v The BladeCenter does not have L2 interfaces but has Management Modules which have L2 interfaces. To view the L2 interfaces of the Management Modules contained in the BladeCenter, complete the following steps: 1. In the Details pane, click the Chassis tab to open the Chassis notebook. 2. Click the MMs tab to open the Management Module notebook. 3. In the Computer System column, click BladeCenter Management Module. 4. Click the IP tab to view the L2 interface details.
205
v v v v v v v v v v v
phys.physpkg.PhysicalFrame phys.physpkg.PowerSupply sys.blade.Alert sys.blade.BladeCenterManagementModule sys.blade.LoginProfile sys.ComputerSystem sysControlSoftware sys.DNSService sys.LDAPService sys.ServiceAccessPoint sys.SMTPService
206
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
207
To configure the access list, enter the following information: v For SNMP V1 and V2 discovery, enter the correct Community String into the access list. You can do this using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
NetFlow sensor
The NetFlow sensor discovers network traffic information that is collected by the Tivoli Netcool Performance Flow Analyzer server. Tivoli Netcool Performance Flow Analyzer is a flow-based, network profiling system that analyzes and aggregates NetFlow data. It compiles the network flow data into reports and makes the reports available to the NetFlow sensor. Using Cisco NetFlow, network flow information is collected from routers and switches and is passed, in the form of UDP packets, to a Tivoli Netcool Performance Flow Analyzer server. See the TADDM Installation Guide for information about installing the Tivoli Netcool Performance Flow Analyzer server.
Limitations
A limited amount of Computer System information is discovered by using the NetFlow sensor. After a discovery, many of the fields in the Details tab of the Computer System remain empty. The discovery scope and port information, defined in the scopeFilter and includePorts properties, override any scope or port settings defined for individual discoveries. If you perform a discovery of more than one subset simultaneously, an instance of the NetFlow sensor starts for each subset. One instance of the NetFlow sensor collects computer system and network connection information from all the subnets defined by the scopeFilter property. All other instances of the NetFlow sensor return a null value.
208
processAppToAppData The default value for this attribute is true. The sensor processes the Tivoli Netcool Performance Flow Analyzer a2a (port to port) files for computer system to computer system connections. Change this attribute to false to prevent this processing. ProcessComputerSystemToAppData The default value for this attribute is true. The sensor processes the Tivoli Netcool Performance Flow Analyzer cfa files for system to system information. Change this attribute to false to prevent this processing.
209
ProcessIPv4Data The default value for this attribute is true. Change this attribute to false to filter out the IPv4 data. ProcessIPv6Data The default value for this attribute is true. Change this attribute to false to filter out the IPv6 data. restrictiveIPv4Data The default value for this attribute is true. The sensor requires both computer systems to be in the scope of discovery for the relationship to be created for the IPv4 data. Change this attribute to false to require only one end point to be present. restrictiveIPv6Data The default value for this attribute is true. The sensor requires both computer systems to be in the scope of discovery for the relationship to be created for the IPv6 data. Change this attribute to false to require only one end point to be present. scopeFilter The scope of a discovery using the NetFlow sensor. If a scope filter is set, only information about the subnets or subnet specified is collected. The default value is for no scope filter set. In the results of a discovery, the NetFlow sensor reports all network connections. The connections discovered are through Cisco NetFlow either to or from the computer systems in the scope filter for the sensor. Many of these connections are to or from other computer systems that are outside of the scope filter for the sensor and that might or might not have been previously discovered. 4. Click OK. The NetFlow sensor can retrieve NetFlow reports from the remote Tivoli Netcool Performance Flow Analyzer server. Depending on the network traffic, it can take approximately 24 hours for the remote Tivoli Netcool Performance Flow Analyzer server to produce data that can be read by the NetFlow sensor. To enable retrieval, use one of the following methods: v If the number of report files becomes large, the most efficient method is to mount the report files directory of the remote Tivoli Netcool Performance Flow Analyzer server on the TADDM server. For this method, enter the location of the mounted drive as the value of the collectorDataDirectory attribute, and leave the value of the collectorIP attribute empty. v Configure the TADDM access list, and enter the IP address of the remote server as the value of the collectorIP attribute.
210
211
v sys.ComputerSystem
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
212
v v v v v v v v v
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
PIX sensor
The PIX sensor discovers Cisco PIX devices that are used as IP firewall and network address translation appliances. The PIX sensor gathers data about the CiscoPIX operating system running on PIX devices. In addition the sensor does the following: v Discovers all real servers and virtual services running. Real servers are grouped into the real servers group.
213
v Discovers the virtualIp, realIp, virtualPort, and realPort, and derives virtual IPs using them. Virtual IPs are stored in the Vip table.
Prerequisite
For configurations that have multiple context configurations, specify in the discovery scope the IP address of the admin context.
Limitations
When topologies are displayed, the following limitations apply: v For context configurations, the virtual and admin contexts are represented by the same icon. v In the physical infrastructure topology view, the connection between the admin context and the virtual context is not displayed. This connection is displayed in the contextual topology view.
214
215
v For SNMP V1 and V2 discovery, enter the correct Community String into the access list. You can do this using the Network Template (SNMP) Component Type in the Access List window in the Discovery Management Console. v For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into the access list, according to the SNMP V3 credential mapping information in the following table:
Map from this: Authentication type (MD5, for example) MD5 Secret Key Private Authentication Description or Key To this: Authentication Protocol Password and Confirm Password Private Password
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
216
snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "Y1UN9;4b/1tz9l#" 10.199.250.9 .1.3.6.1.2.1.1.2.0 SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.400 snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "Y1UN9;4b/1tz9l#" 10.199.250.9 .1.3.6.1.2.1.1.4.0 SNMPv2-MIB::sysContact.0 = STRING: Network Support - CH snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9 .1.3.6.1.2.1.1.5.0 SNMPv2-MIB::sysName.0 = STRING: NC89ZNC01TSL302 snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A " -x DES -X "" 10.199.250.9 .1.3.6.1.2.1.1.6.0 SNMPv2-MIB::sysLocation.0 = STRING: NC89ACB01
The SNMP MIB2 sensor discovers IPv4 and IPv6 information. Using the IP-MIB and IP-FORWARD-MIB modules (updated in RFC 4293 and RFC 4292), the sensor collects IP interface, forwarding, and routing information. The following OIDs are queried:
1.3.6.1.2.1.4.34 IP-MIB (ipAddressTable) 1.3.6.1.2.1.4.32 IP-MIB (ipAddressPrefixTable) 1.3.6.1.2.1.4.25 IP-MIB (ipv6IpForwarding) 1.3.6.1.2.1.4.1 IP-MIB (ipForwarding) 1.3.6.1.2.1.4.24.7 IP-FORWARD-MIB (inetCidrRouteTable)
ipAddressTable This table lists the IPv4 and IPv6 addresses. ipAddressPrefixTable This table lists the prefix information for all addresses. ipv6IpForwarding This flag indicates whether the target device is acting as a router to forward IPv6 packets. ipForwarding This flag indicates whether the target device is acting as a router to forward IPv4 packets. inetCidrRouteTable This IP routing table lists the routes for both IPv4 and IPv6 interfaces. If the target device supports the necessary versions of the IP-MIB and IP-FORWARD-MIB modules, the SNMP MIB2 sensor collects all the required information, and discovery completes. If the target device does not support the necessary versions of these modules, the older versions (RFC 2011 and RFC 1213), which gather only IPv4 information, are used, and the following OIDs are queried:
1.3.6.1.2.1.4.20 IP-MIB (ipAddrTable) 1.3.6.1.2.1.4.1 IP-MIB (ipForwarding) 1.3.6.1.2.1.4.21 RFC1213-MIB (ipRouteTable)
In addition, if the target device is a Cisco device, the CISCO-IETF-IP-MIB and CISCO-IETF-IP-FORWARDING-MIB modules are used to gather just the IPv6 information, and the following OIDs are queried:
1.3.6.1.4.1.9.10.86.1.1.2 CISCO-IETF-IP-MIB (cIpAddressTable) 1.3.6.1.4.1.9.10.86.1.1.1 CISCO-IETF-IP-MIB (cIpAddressPfxTable) 1.3.6.1.4.1.9.10.86.1.2.1 CISCO-IETF-IP-MIB (cIpv6Forwarding) 1.3.5.1.4.9.10.85.7 CISCO-IETF-IP-FORWARD-MIB (cInetCidrRouteTable)
217
Limitations
TADDM currently supports a limited number of network devices. In addition, TADDM L2 switches are switches and L3 switches are routers. So, L3 switches are displayed as a Router in the Physical Infrastructure tree and in the Topology. All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 v multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 v unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0 Therefore, IP networks are not populated in the TADDM user interface.
218
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
219
220
Prerequisites
A discovery user needs to have access to both OSS and Guardian environment. An ASD script is executed from OSS environment. You can create ASD package by running the following command on one line:
dist/bin/makeASDScriptPackage.sh outputDir <output dir> --uname NONSTOP_KERNEL ipAddress <IP> --packingMethod tar --sensors computersystem
Limitations
The sensor is supported only in the Asynchronous discovery mode (ASD). The sensor discovers the limited set of Computer System details. The Generic Server Sensor that starts Level 3 sensors is not supported on the HP NonStop platform.
221
General problems
Verify that the following sensors are enabled in the profile: v ASDPingSensor v ASDSensor v GenericComputerSystemSensor v HpNonStopComputerSystemSensor Verify that the ASD packages are available for a discovery in a directory defined by property com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory.
Prerequisites
For a VM Host system on an Itanium platform, the TADDM service account must have Execute permissions on the hpvmstatus and hpvminfo binary files. For a guest system on an Itanium platform, the TADDM service account must have Execute permissions on the hpvminfo binary files. The TADDM service account must have Execute permissions on the machinfo binary files.
Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0
Therefore, IP networks are not populated in the TADDM user interface. Discovery of IPv6 address of a guest system through a VM Host is not available for HP-UX on an Itanium platform. Discovery of IPv6 address of a VM Host through a guest system is not available for HP-UX on an Itanium platform.
222
Guest systems that are running non-HP-UX operating systems are not created during discovery of the VM host systems.
223
com.collation.platform.os.command.machinfo This property specifies the path to the machinfo command. If this property is not set, the default value of /usr/contrib/bin/machinfo is used. com.collation.discover.agent.command.kcmodule This property specifies the path to the kcmodule command. com.collation.platform.os.HpUxItanium.Model Used as a starting point for HpUx on Itanium. The default value is ia64. Change this property when the model command on HP-UX Itanium systems does not contain ia64 in the output. com.collation.discover.agent.command.hpvminfo This property specifies the path to the hpvminfo command. If this property is not set, the default value of /opt/hpvm/bin/hpvminfo is used. com.collation.discover.agent.command.hpvmstatus This property specified the path to the hpvmstatus command. If this property is not set, the default value of /opt/hpvm/bin/hpvmstatus is used. com.collation.platform.os.command.crontabEntriesCommand.HP-UX=crontab -l This property is used to discover crontab entries. You can specify this property as a scoped property by appending an IP address or a scope set name to the property. The following example uses an appended IP address:
com.collation.platform.os.command.crontabEntriesCommand.HP-UX.1.2.3.4=crontab -l
com.collation.platform.os.command.crontabEntriesUsers.HP-UX=root This property is used to discover crontab entries for a specified user, use a comma-separated list to specify more than one user. You can specify this property as a scoped property by appending an IP address or a scope set name to the property. The following example uses an appended IP address:
com.collation.platform.os.command.crontabEntriesUsers.HP-UX.1.2.3.4=root,build
General problems
Verify that the attributes, such as Architecture, processor type, processor speed, Memory size, or Serial number, are not populated. Verify that the output of the model command contains ia64, and if it does not, verify that the target is HP-UX 11.23 on Itanium. Change the com.collation.platform.os.HpUxItanium.Model property to include the unique identifier from the model command output. The Serial number attribute is not populated on Itanium by default. To enable the Serial number attribute, add the following entry in the collation.properties file on the TADDM server:
com.collation.discover.agent.sys.HpUxComputerSystemItaniumAgent.setSerialNumber=true
224
Solution In the collation.properties file, add the |.*machinfo.* pattern to the end of the property:
com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*machinfo.*
Prerequisites
The TADDM user must have access to the entstat command on AIX target systems.
Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 v multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 v unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0 Therefore, IP networks are not populated in the TADDM user interface. The sensor discovers WPARs by using the WPAR name and IP address. After running a discovery, if the IP address or name of WPAR has changed then clear the topology data before running the discovery again. This task avoids the situation, where duplicate WPARs with the same name exist in the database. This limitation does not apply to WPARs where the IP address is not configured. The fully qualified domain name (FQDN) can be obtained for the WPAR from the host name. In this case, TADDM does not request the host name from the DNS server and the name is not displayed.
225
values is populated for an IP address. The value depends on the address type.
Limitations
Some function that is provided by the AIX computer system sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. Computer system templates and extensions are not supported. The following attributes are not discovered: v Level v BuildLevel v ServicePack
226
v PrimaryOwner sys.AixSoftwareComponent v DisplayName v Group v LastModifiedBy v LastModifiedTime v ManagedSystemName v Name v Type sys.aix.AixUnitaryComputerSystem v Name v AdminState v Admininfo v v v v v CPUSpeed CPUType LastModifiedBy LastModifiedTime Manufacturer
v MemorySize v Model v Name v NumCPUs v PrimaryOwner v Type core.LogicalContent v Checksum v Configfile v Content v ContentType v FixedPath v URI core.Version v BuildLevel v Level v ServicePack net.L2Interface v AdminState v Broadcast v v v v ContextIp Description DisplayName Duplex
v Encapsulation v Guid
Chapter 6. Operating system sensors
227
v v v v v v v v v
dev.StorageExtent v AdminState v BasedOn v BlockSize v Capacity v ContextIp v Controller v Description v DeviceID v DisplayName v FreeSpace v ObjectType v Parent dev.StorageVolume v AdminState v BasedOn v v v v v v v v v v v v v v v v v BlockSize Capacity ContextIp Controller Description DeviceID DisplayName FreeSpace HostPaths IOGroup Label ManagedSystemName Name NumOfBlocks NumOfCylinders ObjectType Parent
sys.WPARComputerSystem v WparCPULimits
228
v v v v v
v WparType
com.collation.platform.os.command.crontabEntriesUsers.AIX=root This property is used to discover crontab entries for a specified user, use a comma-separated list to specify more than one user. You can specify this property as a scoped property by appending an IP address or a scope set name to the property. The following example uses an appended IP address:
com.collation.platform.os.command.crontabEntriesUsers.AIX.1.2.3.4=root,build
229
230
This instance is discovered just as a physical Linux or AIX computer system. There are no special TADDM sensors to discover these virtual computer systems any differently than the physical computer systems they emulate. The computer system (LPAR) discovered by the HMC is a shallow computer system. The following key attributes, which form the naming rule, are discovered: v v v v Manufacturer Model Serial number LPAR ID
After discovery, TADDM merges the two instances into a single computer system. VIOS is discovered with the following storage mapping information: v Virtual SCSI adapters v Virtual NPIV adapters v Virtual target devices v Physical volumes v MPIO paths v HBAs You must use the Hmcoperator user to discover storage mapping information. With the discovery of HMC and the storage sensor discovery of LPARs, you can see a mapping between the LPAR disk and the virtual target device of a VIOS.
Limitations
To discover logical partitions (LPARs) and the HMC correctly, you must run the HMC sensor after a discovery of the LPARs.
231
v v v v v v v v v v v v v v v v v v
Description DesiredHugePages DesiredMemorySize DesiredProcessingUnits DesiredProcessors Devices DisplayName FileSystems Fqdn Functions Guid HostSystem IpInterfaces IsVMIDanLPAR L2Interfaces Label ManagedSystemName Manufacturer
v MaxHugePages v Memory v MemoryLimit v v v v v v v v v v v v MemorySize MinHugePages Model Name NumCPUs OSInstalled OSRunning ObjectType PrimaryMACAddress SerialNumber Signature StorageExtent
v SystemId v Type v UncappedWeight v VMID v Virtual sys.ControlSoftware v BuildLevel v ContextIp v v v v DisplayName Fixes Level MajorVersion
232
v v v v
dev.FCPort v DeviceID v TotalNpivPorts v AvailableNpivPorts v Parent v v v v v v Description PhysicalLocationCode Status PermanentAddress ChildPorts SecondaryAddress
sys.FileSystem v Parent v MountPoint sys.Function v Name v Parent sys.HMC v Systemp sys.LocalFileSystem v StorageExtent dev.MediaAccessDevice v v v v v Manufacturer Model Name SerialNumber Status
v Type dev.vios.MpioPath v Controller v Volume v Connection v Status dev.vios.NpivViosVirtualAdapter v ClientStatus v FcPorts dev.SCSIProtocolController v Name v Parent
Chapter 6. Operating system sensors
233
v v v v v
v ObjectType v Description v EndPoints dev.SCSIProtocolEndPoint v Name v Parent v Description app.SoftwareFix v ControlSoftware dev.StorageVolume v Name v Parent v Type v IeeeUniqueVolumeName v Capacity v LUN v Pvid v NumStalePartitions v v v v SerialNumber SystemPState ViosUDID VolumeGroupName
v BasedOn v MpioPaths sys.SystemPComputerSystem v Architecture v AvailableSysProcUnits v CPUCoresEnabled v CPUCoresInstalled v CPUSpeed v v v v v v v CPUType ConfigurableNumSysHugePages ConfigurableSysProcUnits ConfigurableSystemMemory DeconfiguredSysProcUnits DeconfiguredSystemMemory HugePageSize
v Is5250ApplicationCapable v IsCoDMemoryCapable
234
v v v v v v v v v v v v
IsCoDProcessorCapable IsI5OSCapable IsLHCACapable IsLHEACapable IsMicroPartitioningCapable IsSNIMsgPassingCapable IsVIOSCapable Manufacturer MaxNumProcessorsPerLPAR MaxsSharedProcessorPools MemoryAvailableForPartitions MemorySize
235
236
Prerequisites
The sensor requires the following software to be installed and operational: v IBM Portable Utilities for i, which provides OpenSSH and OpenSSL for IBM i. v Qshell, which is a standards-based command interpreter that enables a common development environment. v Portable Application Solutions Environment (PASE), which includes three shells (Korn, Bourne, and C Shell) and over 200 utilities that run as IBM i PASE programs. v The IBM Toolbox for Java, which is a library of Java classes that give Java programs easy access to the IBM i data and resources. For IBM i 7.1, you need the following versions of the required software: v IBM Portable Utilities for i: 5733SC1 *BASE and option 1 (V7R1M0) v Qshell: 5770SS1 option 30 v PASE: 5770SS1 option 33 Note: In IBM i 7.1, the licensed program product JC1 (IBM Toolbox for Java) is no longer provided as a separate product. Instead, it is included as part of 5770SS1 option 3. For IBM i 6.1, you need the following versions of the required software: v IBM Portable Utilities for i: 5733SC1 *BASE and option 1 (V6R1M0) v Qshell: 5761SS1 option 30 v PASE: 5761SS1 option 33 v IBM Toolbox for Java: 5761JC1 For IBM i 5.4 and i5/OS V5R3, you need the following versions of the required software:
Chapter 6. Operating system sensors
237
v v v v
IBM Portable Utilities for i5/OS: 5733SC1 *BASE and option 1 Qshell: 5722SS1 option 30 PASE: 5722SS1 option 33 IBM Toolbox for Java: 5722JC1
Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0
Therefore, IP networks are not populated in the TADDM user interface. TADDM does not support the discovery of IBM i systems when using public key infrastructure (PKI) authentication. To initialize a connection between the TADDM server and an IBM i system, you must use a user name and a password.
238
Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0
Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 v multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 v unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0 Therefore, IP networks are not populated in the TADDM user interface.
239
Limitations
Some function that is provided by the Linux computer system sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. The following functions are not supported: v Computer system templates and extensions v Deep Level 2 discovery
240
v Discovery on Linux systems that are not x86 systems The following attributes are not supported for the L2Interface model object: v AutoNegotiation v Speed v Duplex
com.collation.platform.os.command.crontabEntriesCommand.Linux=crontab -l -u This property is used to discover crontab entries. You can specify this property as a scoped property by appending an IP address or a scope set name to the property. The following example uses an appended IP address:
com.collation.platform.os.command.crontabEntriesCommand.Linux.1.2.3.4=crontab -l -u
com.collation.platform.os.command.crontabEntriesUsers.Linux=root This property is used to discover crontab entries for a specified user, use a comma-separated list to specify more than one user. You can specify this property as a scoped property by appending an IP address or a scope set name to the property. The following example uses an appended IP address:
com.collation.platform.os.command.crontabEntriesUsers.Linux.1.2.3.4=root,build
241
The command vmcp q userid has failed to run or returns a blank value on the target Linux virtual system running on a z/VM operating system. Solution This problem is caused by one of the following conditions: v An incorrect path for the vmcp command on the target Linux virtual system. v The vmcp tool is not installed on the target Linux virtual system. v The sudo command is not configured to run the vmcp command. v The system name is not configured on the z/VM system. To solve this problem, complete the following steps: v Verify that the correct path for the vmcp command is entered in the collation.properties file. See the topic Configuring the collation.properties file entries for details. v Verify that the system name is configured on the z/VM system, the system name cannot be blank. v If the vmcp tool is not installed on the Linux virtual system, you must load it. To load the vmcp device driver, issue the modprobe vmcp command on the Linux guest. v Verify that the sudo command is available. To verify run the following command on the Linux guest where the monitoring agent is installed:
sudo vmcp q userid
If sudo is active and loaded, this command sends the q userid command to the hosting virtual machine, which queries the user ID for the guest. If there is not a requirement to reconcile the Linux virtual system to the host system on the z/VM operating system, it is not necessary to run the vmcp command. You can use the externalized command property (com.collation.discover.agent.command.vmcp.Linux=) in the collation.properties file to set the host system value to a dummy value. You must be able to parse the externalized command with the following command appended to it:
q userid | awk { print $3 }
This produces the echo A B zVMHost q userid | awk {print $3 } which returns the zVMHost name. The host attribute for your virtual systems is set to zVMHost instead of the actual host system name.
242
z/VM guests can be duplicated after multiple discoveries of the same Linux virtual system
Problem Duplicates can occur if the command vmcp q userid returns a blank value on the target Linux virtual system running on a z/VM operating system. Solution You must manually merge these duplicates.
Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 v multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 v unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0 Therefore, IP networks are not populated in the TADDM user interface.
243
If the target system is a Solaris 10 global zone that has local zones with a status of running, the sensor creates a computer system object for each zone and populates the following attributes: v v v v v v v name virtual type VMID host system signature processor name
To retrieve operating system details for the local zone, you must add the IP address of the local zone to the discovery scope.
Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 v multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 v unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0 Therefore, IP networks are not populated in the TADDM user interface. The sensor discovers the number of physical processors if one of the following commands are present on the target system: v psrinfo -p v prtconf and kstat -m cpu_info. The kstat command must return implementation statistics. The sensor discovers the number of processor cores when the command kstat -m cpu_info is present on the target system. The kstat command must return core_id statistics. For the sensor to discover information about promiscuous mode on the Solaris operating system, the following command must be available for the network interface on the target system:
kstat network_interface_name | grep promisc
244
TADDM does not populate the net.IpNetwork attribute on an IPv6 interface if the prefix length value is unspecified or equals zero. The discovered IPv6 addresses are displayed in the TADDM user interface similarly to IPv4 addresses and are accessible using the TADDM API. Because IPv6 addresses use a prefix length value instead of an IPv4 netmask, only one of these values is populated for an IP address. The value depends on the address type.
Limitations
Some function that is provided by the Solaris computer system sensor during a nonscript-based discovery is not supported in an asynchronous or script-based discovery. The following functions are not supported: v Computer system templates and extensions v Deep Level 2 discovery v Zone discovery The following attributes are not supported: v L2Interface AutoNegotiation Speed Duplex v ComputerSystem (global zone) Virtual
Chapter 6. Operating system sensors
245
ChildSystem VMID CPUCoresInstalled CPUDiesInstalled v ComputerSystem (local zone) Virtual HostSystem VMID CPUCoresInstalled CPUDiesInstalled
com.collation.platform.os.command.crontabEntriesUsers.SunOS=root This property is used to discover crontab entries for a specified user, use a comma-separated list to specify more than one user. You can specify this property as a scoped property by appending an IP address or a scope set name to the property. The following example uses an appended IP address:
com.collation.platform.os.command.crontabEntriesUsers.SunOS.1.2.3.4=root,build
246
Note: The sticky bit might be overwritten by the operating system if a patch is applied that updates the ps command. v Configure the ps command to run with sudo access for the TADDM discovery user by completing the following steps: 1. Set the following properties in the $COLLATION_HOME/etc/ collation.properties file: com.collation.platform.os.command.ps.SunOS=sudo /usr/ucb/ps axww com.collation.platform.os.command.psEnv.SunOS=sudo /usr/ucb/ps axwweee com.collation.platform.os.command.psParent.SunOS=sudo ps -elf -o ruser,pid,ppid,comm com.collation.platform.os.command.psUsers.SunOS=sudo /usr/ucb/ps auxw 2. Ensure that sudo access has been granted to the TADDM discovery user by running the following command on the target system:
sudo ps
Discovery fails when carrying out a discovery through IBM Tivoli Monitoring
Problem During a discovery through IBM Tivoli Monitoring, the discovery fails because of a problem running the command cd $HOME;LANG=C zonecfg -z s8-zone info. Solution In the collation.properties file, add the |.*zonecfg.* pattern to the end of the property:
com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*zonecfg.*
247
This sensor uses a discovery approach that is different from other UNIX systems. Rather than running a discovery against local zone systems directly, a global zone system is used to start the ZonesGenericSensor. This is because the lsof tool is unavailable on local zones. To retrieve all operating system details of the local zone, you must include the IP address of the local zone in the discovery scope.
Prerequisites
The credentials for local and global zones must be entered in the access list (either using SSH key-based authentication or SSH login-based authentication).
Security issues
To correctly discover applications running on a local zone, the TADDM service account in the local and global zones must have access to the ps command with full command-line arguments. Use the following method, to ensure access when the root account or the setuid bit are not used. Modify the following properties in the $COLLATION_HOME/etc/ collation.properties file to configure the ps command to use sudo: v com.collation.platform.os.command.ps.SunOS=sudo /usr/ucb/ps axww v com.collation.platform.os.command.psEnv.SunOS=sudo /usr/ucb/ps axwweee v com.collation.platform.os.command.psUsers.SunOS=sudo /usr/ucb/ps auxw
Limitations
Note the following limitations: v The sensor does not create ProcessFileSystemMapping objects for local zones. When a process running on a local zone uses an NFS share, the dependency between the application server and the NFS Server is not created. v When WebLogic 8 (all releases) managed and admin servers are running on local zones, the runtime information is stored using the CustomAppServerSensor. The CustomAppServerSensor is started by the WeblogicVersionSensor. You must include all local and global zone IP addresses in the discovery scope. In addition, ensure that the custom server list contains at least one template to match the WebLogic command line and that the custom server is enabled. v When running a discovery through an anchor server, include the IP addresses of the local and global zones in the same scope set as the anchor. v Internet Protocol version 6 (IPv6) is not supported when running a discovery on a local zone.
248
The following information is obtained from the system controller on the Sun Fire system: v Remote configuration administration operations v Board assignments and board status v Current usage statistics for Capacity on Demand (COD) resources v System board devices and resource usage information v System controller (SC) failover status or role v Platform type, board available component list, the domain state for each domain, and Capacity on Demand (COD) information
Security issues
The TADDM service account must have platform administrator privileges, which means that the account is a member of the UNIX group platadmn. Any user who is a member of the platadmn group has privileges to run the following System Management Services (SMS) commands: v v v v v rcfgadm showboards showcodusage showdevices showfailover
v showplatform
249
v SerialNumber v Type v Virtual sys.sun.SunFireComputerSystem v ChildSystem v Devices v DisplayName v Manufacturer v Model v Name v SerialNumber v Type
com.collation.discover.agent.SysControlAgent.timeout=1200000 This value specifies the time interval in milliseconds to allow the command to run.
250
Increase the value, until the sensor no longer fails with a timeout error.
Solution In the etc/collation.properties file, add the path configuration for command execution (for example, /opt/SUNWSMS/bin):
com.collation.discover.agent.path.SunOS=/usr/local/bin:/bin:/usr/bin: /usr/X11R6/bin:/usr/sbin:/sbin:/opt/SUNWSMS/bin
Prerequisites
The sensor requires the following software: v sudo command tool v lsof diagnostic tool Install both tools in the same path as defined in the access list for accessing the Tru64 UNIX computer system. This installation must be done on each Tru64 UNIX computer system to be discovered. The most tested versions are sudo-1.6.8p9 and lsof-4.78, however, other versions are likely to work, except in the case where the specific package does not support Tru64 UNIX. To get sudo-1.6.8p9 and lsof-4.78, go to the following Web sites: v For sudo-1.6.8p9: http://www.gratisoft.us/sudo/download.html v For lsof-4.78: http://freshmeat.net/projects/lsof/?branch id=6029&release id=19567 Refer to the distributor Web sites or software readme files for a list of restrictions, such as the addition or removal of support for a platform or function. If a particular package has restrictions, TADDM is affected by those restrictions.
Chapter 6. Operating system sensors
251
Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0
The /etc/sudoers must reside on the Tru64 UNIX computer system that is being discovered. For example, to enable the user taddmusr to run the command on any Tru64 UNIX computer system, enter the following line:
taddmusr ANY = NOPASSWD: /sbin/hwmgr
For example, to enable the user taddmusr to run the /sbin/hwmgr command on a specific target system named target, enter the following line:
taddmusr target = NOPASSWD: /sbin/hwmgr
Two commands must be located in the default location on the Tru64 UNIX computer system: /sbin/hwmgr and /usr/sbin/ifconfig.
252
Typically, an account with non-root privilege can be used. The commands that are used by the Tru64 computer system sensor carrying out the discovery can require privilege escalation. Typically, this escalation is done by setting the file access permissions using the sudo command. For more information, see the topic Commands that might require elevated privilege in the Administering topics in the IBM Tivoli Application Dependency Discovery Manager information center.
In the Discovery Management Console, a VM (virtual machine) is represented by a computer system icon that is blue and transparent. The physical instance is discovered by the normal TADDM sensor for the particular guest operating system, such as Linux. It is discovered just like a
253
physical machine, which includes finding typical devices and attributes. No special TADDM sensors are required to discover these virtual machines any differently than the physical machines they emulate. The virtual instance is discovered by the VMware ESX sensor. It primarily uses configuration files (.vmx) and commands on the VMware ESX server to discover a shallow instance with data that can be described as the following: v Attribute data required to match naming rules and create a valid stand-alone VM instance v Certain basic information that the VMware ESX server provides through the vmware-cmd command. v An attribute (primaryMACAddress) that is used to reconcile the shallow virtual instance with any physical instance that can be discovered. There are two user scenarios for a VM discovery: v All-inclusive: When discovering a scope that includes the server and physical instances, everything works as expected. The result is a virtual instance that shows up in the appropriate domain to match its domain name. This virtual instance is populated with all the attributes that a similar physical machine would have. In addition, it has data and relationships regarding the host ESX server, a virtual attribute that gets set to true, and a VMID attribute that gets set to the one specified in the .vmx configuration file. As long as the TADDM server has connectivity and authentication to the VM, this scenario does not present any problems. v VM-only: When discovering a scope that contains only the VM, it shows up as a physical machine with typical attributes, except that VMware intentionally overrides some model and manufacturer data. Therefore, it is possible to determine if a machine is virtual by examining some attributes. However, the icon is the one used for physical computers, and the virtual attribute is not set to true. To ensure all FQDN information about a VM is collected, you must have VMware Tools installed on the VM.
Prerequisites
For VMware ESX server version 3 and 4, the web Access service (service vmware-webAccess) must be running on the target and the port that it runs on must be accessible from the discovery server or its anchor.
Security issues
To discover VMware ESX 3.x, you must set read-only permissions for the non-root TADDM service account in the VMware ESX console or use the root user for discovery. For more information see the VMware community board: http:// www.vmware.com/community/thread.jspa?messageID=454784
254
Limitations
VMware vCenter servers are not discovered by the VMware ESX computer system sensor. If you must discover these servers, use the VMware Virtual Center server sensor. All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 v link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 v multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 v unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0 Therefore, IP networks are not populated in the TADDM user interface. For VMware ESX server version 2.5 (all releases), you can discover virtual systems only that are running.
v sys.UnitaryComputerSystem v sys.vmware.VmwareESX
Chapter 6. Operating system sensors
255
256
Some attribute information is not displayed in the Details panel of the VMware server
Problem The attributes Model, Manufacturer, and Serial Number are blank in the Details panel of the VMware ESX server. (VMware ESX 2.x only) Solution The dmidecode command is not installed or not working properly. This command for the Linux kernel operating systems is not installed by default on VMware ESX 2.x as it is in 3.x versions. This is not required for the discovery. However, if the fields Model, Manufacturer, and Serial Number are required, TADDM needs the dmidecode command installed on the VMware ESX server. For more information see: http://www.nongnu.org/dmidecode/.
257
Windows:
%COLLATION_HOME%\sdk\bin\api -u <username> -p <password> find --depth 1 ComputerSystem > <filename>.xml
An XML file that lists the first-level attributes for all instances of the ComputerSystem class is generated. Look for the short name of the duplicate instances and scroll down to the attribute named <primaryMACAddress>. If the value is different for the two instances, it is necessary to troubleshoot the MAC address assignments in the configuration file on the server, on the VM itself, or both. VM configuration If a VM is configured in NAT or 'host only' mode, the VMwareESX sensor discovers the virtual instance, but the physical instance is not discovered. VM configuration files on the ESX host server The TADDM VMwareESX sensor gathers information from configuration files for each VM to be discovered. These configuration files can be located with the following ESX command:
vmware-cmd l (this is a lower-case L)
This command lists the configuration file for each VM known to the ESX server, indicated by the .vmx extension. These files are in XML format and are not case-sensitive. View the information in the configuration file for the VM that has duplicate instances. Validate the information for each interface to ensure that the MAC address for each line corresponds to an interface on the VM itself.
ethernet0.present = "true" ethernet0.networkName ="VM Network" ethernet0.addressType = "generated" ethernet0.generatedAddress="00:0c:29:c1:a5:ee" ethernet0.generatedAddressOffset = "0" ethernet1.present = "true" ethernet1.networkName = "VM Network" ethernet1.addressType = "generated" ethernet1.generatedAddress="00:0c:29:c1:a5:f8" ethernet1.generatedAddressOffset = "10"
If the values are different in the configuration file or on the VM, correct them and try the discovery again. Configuration on the VM itself On the VM, there is a command that displays the information for each networking interface. On non-Windows systems, the command is ifconfig. On Windows the command is ipconfig. Examine the output and validate the interface/MAC pairings against the ESX configuration file. You can also verify that each interface is working by pinging the associated IP address. Try the discovery again.
258
Recent changes in a VM or movement from one ESX server to another If a VM has been migrated from one ESX server to another, it is possible that the configuration file was changed and that can affect discoveries. If the lines that contain generatedAddress get deleted it can affect discoveries. When migrating VMs in a VirtualCenter environment, any VM with a generated MAC address is going to change it. If there is an existing VM on the ESX server that can be successfully discovered, use the configuration file for that VM as an example and look for any lines that might have been deleted. The ESX server where the VM originated can also be specified as a target in a scope to see if the VM discovers correctly on that ESX server. If there are lines that have been deleted or modified during migration, add or correct them and run the discovery again. Name resolution If the VM cannot resolve to a single machine on the network, it can end up in TADDM as two separate instances. If the VM has multiple interfaces, and all interfaces are visible on the network, multiple valid instances can be found. It might not be possible to merge all instances into a single instance. This is typically caused by a mismatch between hosts files, DNS, NIS, or any other name resolution service. The remedy is to test the name resolution by the machine short name a few times from the VM itself, the ESX server, and the TADDM server. All the responses must match. If they return different responses, modify the name service or hosts files until the results are consistent. Try the discovery again. General network connectivity & routing There are global networking factors to consider in troubleshooting TADDM discoveries. As it relates to VMware discoveries, a firewall or other networking consideration such as SSH might partially obscure discovery of either the ESX server or the VM. If the VM is discovered correctly by the VMware sensor, it is displayed with only a short name label under the Physical Infrastructure: Overview > Systems Tier > Virtual Systems > VMware ESX The VM itself appears only as an object under the heading of Other Ip Device or Other Computer System. In the case where only the VM is discovered correctly by the OS sensor, it is displayed as the appropriate type of Computer System. The virtual instance is not displayed, and the ESX server might not be displayed either. Correct the routing and firewall configuration until the TADDM server can ping and SSH to the ESX server and directly to each of the VMs, then try the discovery again.
259
problem occurs when a sequential discovery is run by using the VMware ESX computer system sensor followed by the VMware Virtual Center server sensor. Solution You must manually merge duplicated VMware ESX servers. The TADDM User's Guide (or the TADDM Using topics) contains information about using the Data Management Portal, including information about discovery tasks, and how to manually merge discovered configuration items.
Prerequisites
For discovery using a gateway, the gateway must be accessible through SSH. To discover Windows systems without using a gateway: v The Windows systems must be accessible through SSH. v Microsoft .NET Framework version 2.0 or higher must be installed on the target Windows systems. v Windows Scripting Host (WSH) 5.6 or higher must be installed on the target Windows systems. Windows Scripting Host is installed with Internet Explorer 6 Service Pack 1 or higher.
Limitations
All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured to be down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces: v v v v loopback for example, 127.0.0.1, 0:0:0:0:0:0:0:1 link-local for example, 169.254.1.1, FE80:0:0:0:0:0:0:1 multicast for example, 224.0.0.1, FF00:0:0:0:0:0:0:1 unspecified for example, 0.0.0.0, 0:0:0:0:0:0:0:0
260
261
3. TADDM also supports SNMP-based discovery of Windows systems. To support SNMP-based discovery, complete the following steps: a. Enable SNMP. b. Ensure that the SNMP MIB2 GET Community string has access permission for MIB2 System, IP, Interfaces, Extended Interfaces, and Host Resources.
WMI-related properties
TADDM relies on Windows Management Instrumentation (WMI) to discover Windows computer systems. TADDM can be configured to restart the WMI service if a problem occurs with WMI. If the WMI service is restarted, all WMI-dependent services that were running before the restart are also restarted. com.collation.platform.os.WindowsOs.AutoDeploy=true The default value is true, which indicates that TADDM can automatically install the WMI provider. Setting the value to false indicates that you can manually deploy the WMI provider. Manual deployment is not supported but can be used for troubleshooting. The following TADDM server properties control the restarting of WMI. Note: The default value for WMI restart is false. Setting the values of the following properties to true might provide more reliable Windows discovery, but you must also consider the potential negative impact of the WMI service being temporarily stopped and restarted. com.collation.RestartWmiOnAutoDeploy=false Restart WMI if a WMI error occurs during automatic deployment of the TADDM WMI Provider. com.collation.RestartWmiOnAutoDeploy.1.2.3.4=false Restart WMI if a WMI error occurs during automatic deployment of the TADDM WMI Provider.
262
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.
If restarting WMI does not correct the problem, use the following Microsoft utilities to troubleshoot WMI problems: WMIDiag The WMIDiag utility is available at the following Web site: http://www.microsoft.com/downloads/ details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d &displaylang=en Follow the instructions to install and run the utility, and verify that WMI is working correctly. Scriptomatic The Scriptomatic utility is available at the following Web site: http://www.microsoft.com/downloads/ details.aspx?familyid=09dfc342-648b-4119-b7eb-783b0f7d1178 &displaylang=en The Scriptomatic utility can be used to generate WMI queries that are similar to those used by TADDM. The following WMI classes are some that TADDM queries: v Win32_Process v Win32_OperatingSystem v Win32_WMISetting v Win32_ComputerSystem Verify that these classes can be queried using the Scriptomatic utility locally on the target system and remotely from the gateway.
263
Solution The following files comprise the WMI provider and are located on the TADDM server in the $COLLATION_HOME/lib/ms/gateway directory: TaddmWmi.dll The WMI provider, which runs TaddmWmi.exe for functionality TaddmWmi.mof Specifies the new WMI methods that are provided by the WMI provider (TaddmWmi.dll) TaddmWmi.exe Called by the WMI provider (TaddmWmi.dll) to run a command TaddmWmi.pdb Contains debugging information for the TaddmWmi.dll file The TADDM WMI installation provider performs the following tasks: 1. As applicable, copies the files in the preceding list to the following directory on each target system that is in the discovery scope (it uses either the Admin$ or C$ directory to do this): %SystemRoot%\System32\ wbem 2. Runs the following commands on each target system: On 32-bit Windows operating systems:
%SystemRoot%\System32\wbem\mofcomp.exe %SystemRoot%\System32\wbem\TaddmWmi.mof %SystemRoot%\System32\regsvr32 /s %SystemRoot%\System32\wbem\TaddmWmi.dll
To troubleshoot WMI or access-related problems, you can run the TADDM WMI installation provider manually. To manually install the provider using the TaddmTool program on the Windows gateway, enter the following commands: 1. cd WINDOWS\temp\taddm.nnnn, where nnnn is a string that identifies the TADDM gateway directory. If fixes have been applied to the TADDM server, more than one gateway directory might be present. The identifier string can be found in the DiscoveryManager.log file after the following item: DTADDM_ID= 2. set TADDM_USERNAME=domain\userid 3. set TADDM_PASSWORD=password_for_userid 4. set TADDM_INTERACTIVE=1 5. TaddmTool InstallProvider -AutoDeploy @ipaddress, where ipaddress is the IP address of the target system
264
3. If it is refused, repeat step b using port 139. If both fail, you have one of the following issues: v There is a firewall preventing the gateway from connecting to the target SMB service. v The SMB service is not running or otherwise not functional. To determine whether the cause is a firewall or the SMB service, complete the following steps: 1. Log onto the target machine through the console or the Terminal Server Client. 2. Run the telnet commands in steps 2and 3 above, where this time <target machine name> is the local machine.
265
If telnet succeeds, a firewall is causing the problem. Otherwise, there is a problem with the SMB service. Do the following: v View the control panel, services, and check if the Server service is running. v Run the following command at the command line: net share One of the shares: c$ or admin$ must exist.
Slow discovery of Windows 2003 SP1 systems, or applications running on those systems
Problem The slow discovery of Windows 2003 SP1 systems, or applications running on those systems, might be a result of a memory leak in the WMI service. Solution Ensure that the following hotfix, available from Microsoft, is installed: http://support.microsoft.com/kb/911262
266
267
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
268
Limitations
File systems discovered by the sensor are not displayed in the user interface. This restriction applies to computer systems running on operating systems other than Windows operating system. Run the api.sh script to see the file systems discovered by this sensor.
269
Map from this: MD5 Secret Key Private Authentication Description or Key
You can do this using the Network Template (SNMPV3) Component Type in the Access List window in the Discovery Management Console.
Security issues
By default, root user privileges are required to discover SAN resources in UNIX environments. Typically, this escalation is done by setting the file access permissions using the setuid (set-user-ID mode bit) term or by using the sudo command.
270
v Speed dev.FCVolume v BlockSize v Controller v DeviceID v FCPLun v Name v NodeWWN v NumOfBlocks v v v v v PortWWN SCSIBus SCSILun SCSITarget Type
dev.SCSIProtocolController v EndPoints v FCPorts v Name dev.SCSIProtocolEndPoint v Name v WorldWideName dev.SCSIVolume v BasedOn v BlockSize v DeviceID v v v v v v v Name NumOfBlocks SCSIBus SCSILun SCSITarget Type RealizedBy
271
Copying the collection engine file to a location accessible to the target host system
The Host storage sensor uses an executable program, the collection engine file to discover storage data. By default, the Host storage sensor copies the collection engine file, to a location on the target host system. After the discovery is complete, the collection engine file is deleted from the host. Root privileges are required to run the collection engine program. Copying an application to a host system that requires root privileges can introduce a security risk. To avoid this risk, the sensor supports a configuration that allows the collection engine to be deployed to, and accessed from, a secure location. To run the collection engine from a secure location, copy the collection engine file to a location that is accessible to the target host system. To copy and configure the collection engine file, complete the following steps: 1. From the taddm_home/dist/osgi/plugins/ com.ibm.cdb.discover.sensor.dev.hoststorage_7.2.0/bin/collection-engine directory on the TADDM server, copy the file to a location that is accessible to the target host system. 2. Restrict ownership and access to the directory to user root. 3. Specify the location of the collection engine file. The location must be accessible from the target host system. To specify the location of the collection engine file, use one of the following options: v For Windows systems, edit the System PATH environment variable on the host system, and type the location of the collection engine directory. v For all other systems, edit the com.collation.discover.agent.path in the collation.properties file on the TADDM server, and type the location of the collection engine directory. Specify the location of the collection engine directory for the appropriate target operating system. v Modify the discovery profile for the Host storage sensor on the TADDM server. Type the path to the collection engine directory in the CollectionEnginePath or the CollectionEngineWindowsPath attribute or both, if required. 4. Modify the discovery profile for the Host storage sensor on the TADDM server. Set the deployCollectionEngine attribute value to false. 5. Verify that correct user permissions are granted. The commands that are used by the Host storage sensor carrying out the discovery can require privilege escalation. Typically, this escalation is done by setting the file access permissions using the setuid (set-user-ID mode bit) term or by using the sudo command. For Windows operating systems, the discovery user must be a member of the Administrators group.
272
The following attributes can be modified: deployCollectionEngine The default value for the deployCollectionEngine attribute is true. The sensor copies the collection engine file to a location on the target host system. After the discovery is complete the collection engine file is deleted from the host. The location is entered in the collectionEnginePath or the collectionEngineWindowsPath attribute. If no path is specified on Windows systems, the collection engine file is copied to the TEMP directory. For all other systems, the collection engine file is copied to the home directory of the user (running the discovery) on the target host system. If the value is false the collection engine file is not copied. collectionEnginePath There is no default value for the collectionEnginePath attribute. Enter the absolute path to the UNIX collection engine directory, if required. collectionEngineWindowsPath There is no default value for the collectionEngineWindowsPath attribute. Enter the absolute path to the Windows collection engine directory, if required. Entering the Windows path when the directory resides on a network drive (created using the net use command), might not work. Instead, enter the Windows path using the UNC (Universal Naming Convention) method. For example, \\hostname\share\CollectionEngine. collectionEngineSudoCommand There is no default value for the collectionEngineSudoCommand attribute. Enter the command to use for privilege escalation on UNIX systems. collectionEngineTimeout The default value for the collectionEngineTimeout attribute is 30. This value specifies the time interval in minutes before a timeout occurs during a discovery. collectionEngineForceUniqueName The default value for the collectionEngineForceUniqueName attribute is false. If the value is false, the collection engine is not renamed when the collection engine is copied to the target system. If the value is true, a time stamp is added to the name of the collection engine before it is copied to the target system. If you want to use sudo to give the discovery user permission to run the collection engine, then the collection engine name cannot be changed. In this case, the default value of false must be used. In environments that use concurrent discovery, if multiple discoveries are performed at the same time, against the same target systems, collisions can occur when deploying the collection engine. In situations like this, the collectionEngineForceUniqueName attribute can be set to true to force the name of the collection engine to be unique on the target system. If this attribute is set to true, sudo cannot be used. If the Host storage sensor is enabled, do not enable the Storage sensor. If both sensors are enabled, some of the storages resources are discovered twice.
273
To configure the access list, complete the following steps: 1. Select ComputerSystem as the Component Type. 2. Specify the access information (user name and password) that TADDM must use for either SSH key-based authentication or SSH login-based authentication to the target computer system. Typically, an account with non-root privilege can be used. The commands that are used by the Host storage sensor carrying out the discovery can require privilege escalation. Typically, this escalation is done by setting the file access permissions using the setuid (set-user-ID mode bit) term or by using the sudo command.
274
275
SCSI bus, SCSI target and SCSI LUN are not displayed correctly
Problem The SCSI bus, SCSI target, and SCSI LUN for an FC volume are not displayed or the correct values are not displayed. Solution TADDM uses the HBA API to discover SCSI information about an FC volume. However, some HBA API libraries might not support these attributes, or might not return the correct values for these attributes. To resolve this problem, the HBA vendor's HBA API library might need to be updated. Ensure that the latest version of the HBA API library is installed on the target host system. If the HBA API library cannot determine the SCSI information, then these attributes are not displayed or might display incorrect values.
Some of these resources can also be discovered by the host storage sensor (for example, data that is related to hosts) and the Fibre Channel switch sensor (for example, data that is related to switches).
276
277
v v v v
dev.RealizesExtent v Source v Target v Type dev.SCSIPath v ArrayVolume v HostEndPoint v LUN v Parent v Volume dev.SCSIProtocolEndPoint v WorldWideName dev.TapeDrive v Label v Type v WorldWideName net.IpAddress v DotNotation v StringNotation net.IpInterface v IpAddress v Parent relation.ConnectedTo v Source v Target v Type storage.Fabric v v v v v v Fcswitch Label Name SourceToken Virtual ZoneSets
278
v v v v v
v Type v WorldWideName v IpInterfaces storage.StoragePool v v v v v v AnsiT10Id Capacity Label Members Raid Level RemainingManagedSpace
v StorageSubSystem v TotalAvailableSpace v TotalManagedSpace storage.StorageSubSystem v AllocatedCapacity v AnsiT10Id v v v v v v v v v v v v v v v v v v AvailabilityState AvailableCapacity CacheSize FCPorts Fqdn IpInterfaces IsNetworkAttached Manufacturer Members MemorySize Model NumCPUs ROMVersion SerialNumber StoragePools Type VolumeGroupCapacity VolumeGroupFreeSpace
279
v v v v v
v Virtual v Paths storage.TapeLibrary v AnsiT10Id v v v v v v Description Devices Manufacturer Model ROMVersion SerialNumber
v TapeMediaChangers v Type storage.TapeMediaChanger v Caption v Description v Fqdn v v v v Label ROMVersion Type WorldWideName
storage.Zone v Active v Description v Name v Parent storage.ZoneSet v Active v Label v Name v Parent v Zones Multiple operating systems: sys.aix.Aix sys.hpux.HpUx sys.linux.Linux sys.netware.Netware sys.OperatingSystem sys.sun.Solaris sys.vmware.VmwareESX
280
sys.windows.WindowsOperatingSystem The following attributes are associated with these model objects: v FQDN v OSConfidence v OSName v OSVersion v Parent v SoftwareComponents v SystemGuid Multiple Computer Environments: sys.aix.AixUnitaryComputerSystem sys.ComputerSystem sys.hpux.HpUxUnitaryComputerSystem sys.linux.LinuxUnitaryComputerSystem sys.sun.SunSPARCUnitaryComputerSystem sys.vmware.VmwareUnitaryComputerSystem sys.windows.WindowsComputerSystem The following attributes are associated with these model objects: v CPUSpeed v CPUType v Devices v FCPorts v FileSystems v v v v v v v v v v v v v Fqdn IpInterfaces Manufacturer MemorySize Model NumCPUs OSInstalled OSRunning SerialNumber Signature Type Name UUID
281
v Name sys.NFSExport v Name v Parent sys.NFSService v Exports v Host v Name Multiple file systems: sys.LocalFileSystem sys.sun.SolarisFileSystem sys.unix.UnixFileSystem sys.windows.WindowsFileSystem The following attributes are associated with these model objects: v AvailableInodes v v v v v AvailableSpace Capacity MountPoint Parent StorageExtent
v TotalInodes v Type sys.SMBExport v Name v Parent v Path v Type sys.SMBService v Exports v Host v Name sys.SoftwareComponent v Name v Parent v SoftwareVersion
282
The tpc.config and the tpc.properties are located in: COLLATION_HOME/osgi/ plugins/com.ibm.cdb.discover.sensor.app.srm.tpc_7.2.0. The sensor uses the following entries in the tpc.properties file to determine which queries to run: com.ibm.cdb.discover.sensor.app.srm.tpc.ArrayQueries This property is related to array resources. By default, the following queries are enabled: ARRAY, ARRAY_SUM_SOURCE, ARRAY_VOLUME_GROUP, ARRAY_DRIVE, ARRAY_PORT, ARRAY_VOLUME. com.ibm.cdb.discover.sensor.app.srm.tpc.HostQueries This property is related to host resources. By default, the following queries are enabled: HOST, HOST_PORT, HOST_DEVICE_GROUP, HOST_DEVICE, HOST_DEVICE_PARTITION, HOST_DEVICE_PARTITION_DEVICE, HOST_FS, HOST_FS_EXPORT, HOST_AGENT, HOST_SCSI_PATH. The HOST_SCSI_PATH query is used to create the end-to-end storage mapping from Fibre Channel volumes on a host to the volumes on a storage array. This query is enabled by default. Depending on how large the storage environment is, running this query can increase the discovery time of the sensor significantly. Hence, when discovering large storage environments, it is better to enable the HOST_SCSI_PATH query only occasionally. To disable this query, do not include the HOST_SCSI_PATH in the property: com.ibm.cdb.discover.sensor.app.srm.tpc.HostQueries. The following example shows the com.ibm.cdb.discover.sensor.app.srm.tpc.HostQueries property with the HOST_SCSI_PATH query disabled: com.ibm.cdb.discover.sensor.app.srm.tpc.HostQueries=HOST,HOST_PORT, HOST_DEVICE_GROUP,HOST_DEVICE,HOST_DEVICE_PARTITION, HOST_DEVICE_PARTITION_DEVICE,HOST_FS,HOST_FS_EXPORT,HOST_AGENT. com.ibm.cdb.discover.sensor.app.srm.tpc.FabricQueries This property is related to fabric resources. By default, the following queries are enabled: FABRIC, ZONE_SET, ZONE. com.ibm.cdb.discover.sensor.app.srm.tpc.SwitchQueries This property is related to switch resources. By default, the following queries are enabled: SWITCH, SWITCH_PORT. com.ibm.cdb.discover.sensor.app.srm.tpc.NASQueries This property is related to NAS resources. By default, the following queries are enabled: NAS_FILER, NAS_CONTROLLER, NAS_VOLUME, NAS_FS, NAS_DEVICE, NAS_FS_EXPORT. com.ibm.cdb.discover.sensor.app.srm.tpc.TapeQueries This property is related to TAPE resources. By default, the following queries are enabled: TAPE_LIBRARY, TAPE_MEDIA_CHANGER, TAPE_DRIVE. com.ibm.cdb.discover.sensor.app.srm.tpc.SummaryQueries This property is related to SUMMARY resources. By default, the following query is enabled: PORT_CONNECTIVITY. The following properties are used to control the discovery of certain types of computer systems by the IBM Tivoli Storage Productivity Center sensor: com.ibm.cdb.discover.sensor.app.srm.tpc.ignoreAixCompSys=true This property determines whether the IBM Tivoli Storage Productivity Center sensor discovers computer systems on AIX operating systems or
283
not. By default, it is set to true which means that the sensor does not discover computer systems on AIX operating systems. com.ibm.cdb.discover.sensor.app.srm.tpc.IgnoreCSWithoutMacaddr=true This property determines whether the IBM Tivoli Storage Productivity Center sensor discovers computer systems without a MAC address. By default, it is set to true which means that the sensor does not discover computer systems without a MAC address.
284
Problems connecting to the Tivoli Storage Productivity Center database cause sensor failure
Problem The sensor fails due to problems connecting to the Tivoli Storage Productivity Center database. Solution Verify that the DB2 credentials of the Tivoli Storage Productivity Center database have been entered.
285
v Zones on Solaris systems discovered by TPCStorageSensor and SunSparcComputerSystemSensor To ensure that there is no duplication of computer systems, in the TADDM UI you must select the duplicate computer systems and merge them manually.
where X is the maximum number of rows the sensor processes for this query. If this value is greater than 20,000: v Increase the heap size allocated for the Discover JVM. Edit the $COLLATION_HOME/etc/collation.properties and change the com.collation.Discover.jvmargs.ibm property. For example, to set the heap size to 1824 MB, add the following line:
com.collation.Discover.jvmargs.ibm=-Xdisableexplicitgc -Xmx1824m
v Increase the agent timeout for the Discover JVM. In the $COLLATION_HOME/etc/collation.properties file, add the following property, where value is the number of milliseconds allowed for the sensor to run:
com.collation.discover.agent.TPCStorageSensor.timeout=value
If you do not specify a value, the default value of 600000 is used. v Restart TADDM. Restrict the scope of storage arrays and Computer systems discovered The number of rows returned by the HOST_SCSI_PATH query can be reduced by restricting the scope of the arrays and computer systems discovered. 1. From the Discovery Management Console, click the Scope icon. Select the Scope Set that contains the Tivoli Storage Productivity Center server to be discovered. Include the IP
286
address, Range, or Subnet information of the arrays and computers system to be discovered. The IP address of the storage arrays and IP address of the computer system must be in the same scope set as the Tivoli Storage Productivity Center server for the discovery. These values enable the SCSI path data to be included in the results of the discovery. 2. From the Discovery Management Console, click the Discovery Profiles icon. 3. In the Discovery Profiles window, click New. 4. In the Create New Profile window, type the profile name and description. In the Clone existing profile field, click Level 3 Discovery , and click OK. 5. In the list of sensors, click TPCStorageSensor, and click New. 6. In the Create Configuration window, type the name and description for your configuration of the TPCStorageSensor, and select the Enable Configuration check box. 7. In the Configuration section of the Create Configuration window, to restrict the scope of discovery, click restrictByScope. Then double-click the Value field in the row, and type true. 8. Click OK to return to the Discovery Profiles window. 9. In the Discovery Profiles window, click Save. 10. Start a discovery using the new profile. After a discovery using the sensor, review the $COLLATION_HOME/log/sensors/runId/TPCStorageSensor-IPPORT.log(.N) to see the number of SCSI paths that exist per storage array IP address and per host IP address. The following text is an example of the contents of the log file:
SCSI PATH statistics by host ip address : ip#1/4 with ipAddress 10.3.41.230 has 160 valid scsi paths ip#2/4 with ipAddress 10.3.41.289 has 527 valid scsi paths ip#3/4 with ipAddress 10.3.43.19 has 108 valid scsi paths ip#4/4 with ipAddress 10.3.42.211 has 160 valid scsi paths SCSI PATH statistics by array ip address: ip#1/2 with ipAddress 10.0.15.201 has 693 valid scsi paths ip#2/2 with ipAddress 10.0.17.2 has 736 valid scsi paths
Run a discovery with the Tivoli Storage Productivity Center server in a scope of its own To get the complete result set of the HOST_SCSI_PATH query and prevent out-of-memory errors: 1. Create a Scope Set containing only the Tivoli Storage Productivity Center server (with no other targets). 2. Create a discovery profile with only the TPCStorageSensor and its dependent sensors enabled. 3. Start the discovery of the scope set containing the Tivoli Storage Productivity Center server using the new profile.
287
Storage sensor
The storage sensor discovers the storage that is attached to a computer system. The following resources are examples of what the sensor discovers: v v v v v Disks Partitions Logical volumes Physical volumes File systems
Limitations
Access to the /dev/dsk directory is not available on Solaris local or branded zone target systems. Therefore, not all storage information is retrieved.
288
Typically, an account with non-root privilege can be used. However, some commands that TADDM uses during the discovery process can require privilege escalation (typically done using the sudo command). For more information, see the topic Commands that might require elevated privilege in the Administering topics in the TADDM information center.
General problems
Determine whether information is missing, and identify any command failures due to permissions denied errors. Verify that commands that require privilege escalation are properly configured. See Configuring the collation.properties file entries for details.
289
v Installation directory v Objects under the control of VxVM (for example, Volumes and Disk Groups) and relationships between them. The second component, VERITAS File System, is recognized as a local file system and the disk layout version is collected.
Security issues
The default user to discover Computer System is used.
Limitations
The licenses are not supported. There are no application descriptors.
290
291
292
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement might not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
293
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. If you are viewing this information in softcopy form, the photographs and color illustrations might not be displayed.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at http://www.ibm.com/legal/copytrade.shtml.
294
Itanium is a trademark or registered trademark of Intel Corporation or its subsidiaries in the United States and other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others.
Notices
295
296
Printed in USA