application dependency discovery manager: sensors

Tivoli Application Dependency DiscoveryManagerVersion 7.3

Sensor Reference

IBM

Note

Before using this information and the product it supports, read the information in “Notices” on page421.

Edition notice

This edition applies to version 7, release 3 of IBM® Tivoli® Application Dependency Discovery Manager (product number5724-N55) and to all subsequent releases and modifications until otherwise indicated in new editions.© Copyright International Business Machines Corporation 2008, 2020.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract withIBM Corp.

Contents

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

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

About this information.......................................................................................... xiConventions used in this information center..............................................................................................xiTerms and definitions..................................................................................................................................xi

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

Sensors that are enabled by default...................................................................................................... 1Sensors that support a non-admin discovery on Windows operating system......................................8Sensors that support script-based and asynchronous discovery......................................................... 9Sensors that support discovery using IBM Tivoli Monitoring (old method)....................................... 11Sensors that support discovery using OSLC Automation ...................................................................13Sensor setup problems........................................................................................................................ 13

Application sensors................................................................................................................................... 14Active Directory sensor........................................................................................................................ 14Apache sensor...................................................................................................................................... 16Citrix server sensor...............................................................................................................................19Docker Host sensor.............................................................................................................................. 24Docker Swarm Cluster sensor..............................................................................................................31DNS sensor........................................................................................................................................... 34HIS sensor............................................................................................................................................ 34IBM Cluster Systems Management sensor..........................................................................................39IBM High-Availability Cluster Multi-Processing sensor.......................................................................41IBM Lotus Domino server sensor.........................................................................................................45IBM Tivoli Monitoring Scope sensor.................................................................................................... 48IBM WebSphere sensor........................................................................................................................61IBM WebSphere eXtreme Scale cache sensor.................................................................................... 79IBM WebSphere Message Broker sensor............................................................................................ 81IBM WebSphere MQ Server sensor......................................................................................................83iPlanet server sensor............................................................................................................................86JBoss server sensor............................................................................................................................. 86JBoss Application Server 7 sensor...................................................................................................... 89Kernel-based virtual machine sensor..................................................................................................93Microsoft Cluster sensor...................................................................................................................... 94Microsoft Exchange sensor.................................................................................................................. 97Microsoft Exchange 2003 sensor...................................................................................................... 108Microsoft HyperV sensor....................................................................................................................113Microsoft IIS Web server sensor....................................................................................................... 114NFS sensor......................................................................................................................................... 120Pacemaker Cluster sensor................................................................................................................. 120Oracle Application Server sensor...................................................................................................... 122SAP CCMS server sensor....................................................................................................................126SAP SLD server sensor.......................................................................................................................130SMB server sensor............................................................................................................................. 134SMS server sensor..............................................................................................................................135SysImager sensor.............................................................................................................................. 136

iii

Veritas cluster sensor........................................................................................................................ 138VMware Virtual Center server sensor................................................................................................ 140WebLogic sensor................................................................................................................................ 150WebLogic SSH sensor.........................................................................................................................159

Cloud sensor............................................................................................................................................ 167AWS sensor........................................................................................................................................ 167

Database sensors.................................................................................................................................... 173IBM DB2 sensor................................................................................................................................. 173IBM Informix sensor.......................................................................................................................... 178Microsoft SQL Server sensor..............................................................................................................181Oracle sensor..................................................................................................................................... 186Sybase sensor.................................................................................................................................... 196Sybase IQ sensor............................................................................................................................... 203

Generic sensors....................................................................................................................................... 204Anchor sensor.................................................................................................................................... 204Asynchronous discovery sensor........................................................................................................ 206Asynchronous discovery ping sensor................................................................................................ 206Custom application server sensor..................................................................................................... 207Custom MIB2 computer system sensor............................................................................................ 208Custom template sensor....................................................................................................................208Generic computer system sensor......................................................................................................212Generic server sensor........................................................................................................................ 212IBM Tivoli Utilization sensor.............................................................................................................. 215IP device sensor.................................................................................................................................222IP interface sensor.............................................................................................................................222Ping sensor......................................................................................................................................... 223Port sensor......................................................................................................................................... 226Session sensor................................................................................................................................... 226Solaris zones generic sensor............................................................................................................. 229Stack Scan sensor.............................................................................................................................. 230WPAR generic sensor......................................................................................................................... 237zEnterprise sensor............................................................................................................................. 238

Network sensors......................................................................................................................................245Overview of SNMP sensors................................................................................................................ 245Alteon port sensor..............................................................................................................................249Alteon SNMP sensor...........................................................................................................................250Alteon VLAN sensor........................................................................................................................... 252BIG-IP port sensor.............................................................................................................................253BIG-IP SNMP sensor..........................................................................................................................253BIG-IP VLAN sensor...........................................................................................................................255Bridge SNMP sensor...........................................................................................................................256Bridge SNMP 2 sensor........................................................................................................................258Check Point sensor.............................................................................................................................260Check Point SNMP sensor..................................................................................................................261Cisco Adaptive Security Appliance sensor........................................................................................ 262Cisco Discovery Protocol sensor........................................................................................................263Cisco IOS sensor................................................................................................................................ 264Cisco port sensor................................................................................................................................265Cisco UCS SNMP sensor.....................................................................................................................266Cisco VLAN sensor............................................................................................................................. 269CiscoWorks sensor............................................................................................................................. 270Entity MIB sensor...............................................................................................................................272Extreme VLAN sensor........................................................................................................................ 273IBM BladeCenter SNMP sensor......................................................................................................... 274LAN Manager SNMP sensor............................................................................................................... 277LDAP sensor....................................................................................................................................... 278Link Layer Discovery Protocol sensor................................................................................................280NetScreen SNMP sensor.................................................................................................................... 281

iv

Nokia SNMP sensor............................................................................................................................282PIX sensor.......................................................................................................................................... 283SNMP Light sensor............................................................................................................................. 284SNMP MIB2 sensor............................................................................................................................ 286

Operating system sensors.......................................................................................................................290Citrix XenServer sensor......................................................................................................................290DataPower sensor.............................................................................................................................. 292FreeBSD computer system sensor.................................................................................................... 294HP BladeSystem SNMP sensor.......................................................................................................... 298HP NonStop computer system sensor...............................................................................................300HP-UX computer system sensor........................................................................................................301IBM AIX computer system sensor.....................................................................................................306IBM Hardware Management Console sensor....................................................................................312IBM Integrated Virtualization Manager sensor................................................................................. 319IBM i computer system sensor.......................................................................................................... 320IPSO computer system sensor.......................................................................................................... 321Linux computer system sensor..........................................................................................................322OpenVMS computer system sensor...................................................................................................330Solaris computer system sensor....................................................................................................... 332Sun Sparc Virtualization sensor.........................................................................................................338Sun Fire SysControl sensor................................................................................................................340Tru64 computer system sensor.........................................................................................................342VMware ESX computer system sensor..............................................................................................344VMware ESXi computer system sensor............................................................................................. 349Windows computer system sensor....................................................................................................352

Storage sensors....................................................................................................................................... 371EMC Storage Scope sensor................................................................................................................ 371EMC ViPR SRM Sensor....................................................................................................................... 377Fibre Channel switch sensor..............................................................................................................385Host resources sensor....................................................................................................................... 387Host storage sensor........................................................................................................................... 388IBM Tivoli Storage Productivity Center sensor..................................................................................396NetApp sensor....................................................................................................................................408Snap Drive sensor.............................................................................................................................. 409Storage sensor................................................................................................................................... 410SVC Storage sensor............................................................................................................................ 412Veritas Storage Foundation sensor....................................................................................................414XIV Storage sensor.............................................................................................................................416

Notices..............................................................................................................421Trademarks.............................................................................................................................................. 422

v

Figures

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

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

vii

Tables

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



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

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

6. Database sensors that support a non-admin discovery on Windows operating system............................ 8

7. Generic sensors that support a non-admin discovery on Windows operating system............................... 8

8. Operating system sensors that support a non-admin discovery on Windows operating system............... 8

9. List of script-based sensors.......................................................................................................................... 9

10. Sensors that support discovery using IBM Tivoli Monitoring.................................................................. 12

11. Sensors that support discovery using OSLC Automation.........................................................................13

12. Citrix 7 to Citrix 6 mapping....................................................................................................................... 22

13. Package names of the SAP JCo 2.x library files..................................................................................... 127

14. Required WebLogic JAR files..................................................................................................................152

15. Windows Gateway...................................................................................................................................171

16. Target (EC2 instance)..............................................................................................................................171

17. Anchor..................................................................................................................................................... 172

18. Target (EC2 instance)..............................................................................................................................172

19. Configuration parameters.......................................................................................................................218

20. Foundry OID mapping example..............................................................................................................247

21. Level 2 bridge topology data.................................................................................................................. 256

22. SNMP V3 credential mapping.................................................................................................................268

23. SNMP V3 credential mapping.................................................................................................................299

ix

24. Solaris virtualization type discovery.......................................................................................................339

x

About this information

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

Conventions used in this information centerIn the IBM Tivoli Application Dependency Discovery Manager (TADDM) documentation certainconventions are used. They are used to refer to the operating system-dependent variables and paths, theCOLLATION_HOME directory, and the location of the collation.properties file, which is referencedthroughout the TADDM documentation, including in the messages.

Operating system-dependent variables and pathsIn this information center, the UNIX conventions are used for specifying environment variables and fordirectory notation.

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

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

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

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

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

Location of collation.properties fileThe collation.properties file contains TADDM server properties and includes comments about eachof the properties. It is located in the $COLLATION_HOME/etc directory.

Terms and definitionsRefer to the following list of terms and definitions to learn about important concepts in the IBM TivoliApplication Dependency Discovery Manager (TADDM).

access collectionA collection that is used to control the access to configuration items and permissions to modifyconfiguration items. You can create access collections only when data-level security is enabled.

asynchronous discoveryIn TADDM, the running of a discovery script on a target system to discover systems that cannot beaccessed directly by the TADDM server. Because this discovery is performed manually, and separatelyfrom a typical credentialed discovery, it is called "asynchronous".

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

CISee configuration item.

collectionIn TADDM, a group of configuration items.

© Copyright IBM Corp. 2008, 2020 xi

configuration item (CI)A component of IT infrastructure that is under the control of configuration management and istherefore subject to formal change control. Each CI in the TADDM database has a persistent objectand change history associated with it. Examples of a CI are an operating system, an L2 interface, and adatabase buffer pool size.

credentialed discoveryTADDM sensor scanning that discovers detailed information about the following items:

• Each operating system in the runtime environment. This scanning is also known as Level 2discovery, and it requires operating system credentials.

• The application infrastructure, deployed software components, physical servers, network devices,virtual systems, and host data that are used in the runtime environment. This scanning is alsoknown as Level 3 discovery, and it requires both operating system credentials and applicationcredentials.

credential-less discoveryTADDM sensor scanning that discovers basic information about the active computer systems in theruntime environment. This scanning is also known as Level 1 discovery, and it requires no credentials.

Data Management PortalThe TADDM web-based user interface for viewing and manipulating the data in a TADDM database.This user interface is applicable to a domain server deployment, to a synchronization serverdeployment, and to each storage server in a streaming server deployment. The user interface is verysimilar in all deployments, although in a synchronization server deployment, it has a few additionalfunctions for adding and synchronizing domains.

discover worker threadIn TADDM, a thread that runs sensors.

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

discovery serverA TADDM server that runs sensors in a streaming server deployment but does not have its owndatabase.

domainIn TADDM, a logical subset of the infrastructure of a company or other organization. Domains candelineate organizational, functional, or geographical boundaries.

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

domain server deploymentA TADDM deployment with one domain server. A domain server deployment can be part of asynchronization server deployment.

In a domain server deployment, the following TADDM server property must be set to the followingvalue:

com.collation.cmdbmode=domain

launch in contextThe concept of moving seamlessly from one Tivoli product UI to another Tivoli product UI (either in adifferent console or in the same console or portal interface) with single sign-on and with the target UIin position at the proper point for users to continue with their task.

Level 1 discoveryTADDM sensor scanning that discovers basic information about the active computer systems in theruntime environment. This scanning is also known as credential-less discovery because it requires nocredentials. It uses the Stack Scan sensor and the IBM® Tivoli® Monitoring Scope sensor. Level 1discovery is very shallow. It collects only the host name, operating system name, IP address, fully

xii About this information

qualified domain name, and Media Access Control (MAC) address of each discovered interface. Also,the MAC address discovery is limited to Linux on System z® and Windows systems. Level 1 discoverydoes not discover subnets. For any discovered IP interfaces that do not belong to an existing subnetthat is discovered during Level 2 or Level 3 discovery, new subnets are created based on the value ofthe com.collation.IpNetworkAssignmentAgent.defaultNetmask property in thecollation.properties file.

Level 2 discoveryTADDM sensor scanning that discovers detailed information about each operating system in theruntime environment. This scanning is also known as credentialed discovery, and it requires operatingsystem credentials. Level 2 discovery collects application names and the operating system names andport numbers that are associated with each running application. If an application has established aTCP/IP connection to another application, this information is collected as a dependency.

Level 3 discoveryTADDM sensor scanning that discovers detailed information about the application infrastructure,deployed software components, physical servers, network devices, virtual systems, and host data thatare used in the runtime environment. This scanning is also known as credentialed discovery, and itrequires both operating system credentials and application credentials.

multitenancyIn TADDM, the use by a service provider or IT vendor of one TADDM installation to discover multiplecustomer environments. Also, the service provider or IT vendor can see the data from all customerenvironments, but within each customer environment, only the data that is specific to the respectivecustomer can be displayed in the user interface or viewed in reports within that customerenvironment.

Product ConsoleSee Discovery Management Console.

script-based discoveryIn TADDM, the use, in a credentialed discovery, of the same sensor scripts that sensors provide insupport of asynchronous discovery.

SESee server equivalent.

server equivalent (SE)A representative unit of IT infrastructure, defined as a computer system (with standard configurations,operating systems, network interfaces, and storage interfaces) with installed server software (such asa database, a web server, or an application server). The concept of a server equivalent also includesthe network, storage, and other subsystems that provide services to the optimal functioning of theserver. A server equivalent depends on the operating system:

Operating system Approximate number of CIs

Windows 500

AIX 1000

Linux 1000

HP-UX 500

Network devices 1000

storage serverA TADDM server that processes discovery data that is received from the discovery servers and storesit in the TADDM database. The primary storage server both coordinates the discovery servers and allother storage servers and serves as a storage server. All storage servers that are not the primary arecalled secondary storage servers.

About this information xiii

streaming server deploymentA TADDM deployment with a primary storage server and at least one discovery server. This type ofdeployment can also include one or more optional secondary storage servers. The primary storageserver and secondary storage servers share a database. The discovery servers have no database.

In this type of deployment, discovery data flows in parallel from multiple discovery servers to theTADDM database.

In a streaming server deployment, the following TADDM server property must be set to one of thefollowing values:

• com.collation.taddm.mode=DiscoveryServer• com.collation.taddm.mode=StorageServer

For all servers except for the primary storage server, the following properties (for the host name andport number of the primary storage server) must also be set:

• com.collation.PrimaryStorageServer.host• com.collation.PrimaryStorageServer.port

If the com.collation.taddm.mode property is set, the com.collation.cmdbmode property must not beset or must be commented out.

synchronization serverA TADDM server that synchronizes discovery data from all domain servers in the enterprise and has itsown database. This server does not discover data directly.

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

In this type of deployment, the synchronization server copies discovery data from multiple domainservers one domain at a time in a batched synchronization process.

In a synchronization server deployment, the following TADDM server property must be set to thefollowing value:

com.collation.cmdbmode=enterprise

This type of deployment is obsolete. Therefore, in a new TADDM deployment where more than oneserver is needed, use the streaming server deployment. A synchronization server can be converted tobecome a primary storage server for a streaming server deployment.

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

Each TADDM server, except for discovery servers and secondary storage servers, has its owndatabase. Discovery servers have no database. Storage servers share the database of the primarystorage server.

TADDM serverA generic term that can represent any of the following terms:

• domain server in a domain server deployment• synchronization server in a synchronization server deployment• discovery server in a streaming server deployment• storage server (including the primary storage server) in a streaming server deployment

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

utilization discoveryTADDM sensor scanning that discovers utilization information for the host system. A utilizationdiscovery requires operating system credentials.

xiv Application Dependency Discovery Manager: Sensors

Chapter 1. Sensor reference

OverviewFor 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 theattributes that are associated with the model objects is also included. Where attributes are included, theattributes are available in the IBM Tivoli Common Data Model (CDM) but are not necessarily shown in theIBM Tivoli Application Dependency Discovery Manager (TADDM) UI.

Sensors and supported target systemsFor the list of the TADDM sensors and the supported versions of target systems that they can discover, seeSensors and supported target systems in the TADDM Wiki.

Discovery process overviewThe TADDM Administrator's Guide contains an overview of the discovery process, including informationabout how a sensor discovers configuration items (CIs) and how an application sensor is started.

Late-breaking updatesFor late-breaking updates about TADDM 7.3.0 sensor support issues, see Release notes in the TADDMdocumentation.

Sensor extensionsIf you want to discover additional software that is not discovered by TADDM by default, you can createcustom server templates. You can create your own templates or use predefined templates. For details,see the Creating and managing custom server templates topic in the TADDM User's Guide.

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

For more information about levels of discovery, see the Levels of discovery topic in the TADDMAdministrator's Guide.

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

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

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

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

Sensor Sensor name that is used in the UI and logs

“Anchor sensor” on page 204 AnchorSensor

“SNMP Light sensor” on page 284 SnmpLightSensor

“Stack Scan sensor” on page 230 StackScanSensor

© Copyright IBM Corp. 2008, 2020 1

https://github.com/TADDM/taddm-wiki/wiki/Sensors-and-Supported-Target-Systems






“Alteon port sensor” on page 249 AlteonPortSensor

“Alteon SNMP sensor” on page 250 AlteonSnmpSensor

“Alteon VLAN sensor” on page 252 AlteonVlanSensor


“Asynchronous discovery sensor” on page 206 ASDSensor

“BIG-IP port sensor” on page 253 BigIPPortSensor

“BIG-IP SNMP sensor” on page 253 BigIPSnmpSensor

“BIG-IP VLAN sensor” on page 255 BigIPVlanSensor

“Bridge SNMP sensor” on page 256 BridgeSnmpSensor

“Bridge SNMP 2 sensor” on page 258 BridgeSnmpSensor2

“Check Point SNMP sensor” on page 261 CheckpointSnmpSensor

“Cisco Discovery Protocol sensor” on page 263 CdpSensor

“Cisco IOS sensor” on page 264 CiscoIOSSensor

“Cisco port sensor” on page 265 CiscoPortSensor

“Cisco VLAN sensor” on page 269 CiscoVlanSensor

“Custom application server sensor” on page 207 CustomAppServerSensor

“Custom MIB2 computer system sensor” on page208

CustomMib2ComputerSystemSensor

“Entity MIB sensor” on page 272 EntityMIBSensor

“Extreme VLAN sensor” on page 273 ExtremeVlanSensor

“FreeBSD computer system sensor” on page 294 FreeBSDComputerSystemSensor

“Generic computer system sensor” on page 212 GenericComputerSystemSensor

“Generic server sensor” on page 212 GenericServerSensor

“IBM AIX computer system sensor” on page 306 AixComputerSystemSensor

“IBM BladeCenter SNMP sensor” on page 274 BladeCenterSnmpSensor

“IBM Hardware Management Console sensor” onpage 312

HmcSensor

“IBM i computer system sensor” on page 320 I5OSComputerSystemSensor

“IBM Integrated Virtualization Manager sensor” onpage 319

IvmSensor

“Host resources sensor” on page 387 HostResourcesSensor

2 Application Dependency Discovery Manager: Sensors

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


“HP BladeSystem SNMP sensor” on page 298 HPBladeSystemSnmpSensor

“HP NonStop computer system sensor” on page300

HPNonStopComputerSystemSensor

“HP-UX computer system sensor” on page 301 HpUxComputerSystemSensor

“IP device sensor” on page 222 IpDeviceSensor

“IPSO computer system sensor” on page 321 IPSOComputerSystemSensor

“LAN Manager SNMP sensor” on page 277 LanManagerSnmpSensor

“Linux computer system sensor” on page 322 LinuxComputerSystemSensor

“NetApp sensor” on page 408 NetAppSensor

“NetScreen SNMP sensor” on page 281 NetscreenSnmpSensor

“Nokia SNMP sensor” on page 282 NokiaSnmpSensor

“OpenVMS computer system sensor” on page 330 OpenVmsComputerSystemSensor

“Ping sensor” on page 223 PingSensor

“Port sensor” on page 226 PortSensor

“Session sensor” on page 226 SessionSensor

“Snap Drive sensor” on page 409 SnapDriveSensor

“SNMP MIB2 sensor” on page 286 SnmpMib2Sensor

“Solaris computer system sensor” on page 332 SunSparcComputerSystemSensor

“Solaris zones generic sensor” on page 229 ZonesGenericSensor

“Sun Fire SysControl sensor” on page 340 SysControlSensor

Sun Sparc Virtualization sensor SunSparcVirtualizationSensor

SVC Storage sensor SVCStorageSensor

“Tru64 computer system sensor” on page 342 Tru64ComputerSystemSensor

“VMware ESX computer system sensor” on page344

VmwareComputerSystemSensor

“VMware ESXi computer system sensor” on page349

VmwareEsxiComputerSystemSensor

“Windows computer system sensor” on page 352 WindowsComputerSystemSensor

“WPAR generic sensor” on page 237 WparGenericSensor

XIV Storage sensor XIVStorageSensor

“zEnterprise sensor” on page 238 ZEnterpriseSensor




Chapter 1. Sensor reference 3



“Active Directory sensor” on page 14 ActiveDirectorySensor

“Alteon port sensor” on page 249 AlteonPortSensor

“Alteon SNMP sensor” on page 250 AlteonSnmpSensor

“Alteon VLAN sensor” on page 252 AlteonVlanSensor


“Apache sensor” on page 16 ApacheServerSensor

“Asynchronous discovery sensor” on page 206 ASDSensor

“BIG-IP port sensor” on page 253 BigIPPortSensor

“BIG-IP SNMP sensor” on page 253 BigIPSnmpSensor

“BIG-IP VLAN sensor” on page 255 BigIPVlanSensor

“Bridge SNMP sensor” on page 256 BridgeSnmpSensor

“Bridge SNMP 2 sensor” on page 258 BridgeSnmpSensor2

“Check Point sensor” on page 260 CheckpointSensor

“Check Point SNMP sensor” on page 261 CheckpointSnmpSensor

“Cisco Adaptive Security Appliance sensor” onpage 262

• ASASensor• CiscoApplianceVersionSensor

“Cisco Discovery Protocol sensor” on page 263 CdpSensor

“Cisco IOS sensor” on page 264 CiscoIOSSensor

“Cisco port sensor” on page 265 CiscoPortSensor

“Cisco UCS SNMP sensor” on page 266 CiscoUCSSensor

“Cisco VLAN sensor” on page 269 CiscoVlanSensor

“CiscoWorks sensor” on page 270 • CiscoWorks405FileUDS• CiscoWorks405UDS• CiscoWorksFileUDS• CiscoWorksSensor• CiscoWorksUDS

“Citrix server sensor” on page 19 CitrixServerSensor

“Citrix XenServer sensor” on page 290 XenServerSensor

“Custom application server sensor” on page 207 CustomAppServerSensor

“Custom MIB2 computer system sensor” on page208

CustomMib2ComputerSystemSensor

“DNS sensor” on page 34 DnsSensor

“EMC Storage Scope sensor” on page 371 • EMCStorageScopeSensor• EMCStorageScopeDetailSensor




“Entity MIB sensor” on page 272 EntityMIBSensor

“Extreme VLAN sensor” on page 273 ExtremeVlanSensor

“FreeBSD computer system sensor” on page 294 FreeBSDComputerSystemSensor



“HIS sensor” on page 34 HISServerSensor

“Host resources sensor” on page 387 HostResourcesSensor

“HP BladeSystem SNMP sensor” on page 298 HPBladeSystemSnmpSensor

“HP NonStop computer system sensor” on page300

HPNonStopComputerSystemSensor

“HP-UX computer system sensor” on page 301 HpUxComputerSystemSensor


“IBM BladeCenter SNMP sensor” on page 274 BladeCenterSnmpSensor

“IBM DB2 sensor” on page 173 • Db2Sensor• Db2WindowsSensor

“IBM Hardware Management Console sensor” onpage 312

HmcSensor

“IBM High-Availability Cluster Multi-Processingsensor” on page 41

HACMPSensor

“IBM i computer system sensor” on page 320 I5OSComputerSystemSensor

“IBM Informix sensor” on page 178 Informix

“IBM Integrated Virtualization Manager sensor” onpage 319

IvmSensor

“IBM Lotus Domino server sensor” on page 45 • DominoDomainSensor• DominoServerDetailSensor• DominoInitialSensor

“IBM Tivoli Storage Productivity Center sensor” onpage 396

TPCStorageSensor

“IBM WebSphere eXtreme Scale cache sensor” onpage 79

WebSphereXSCacheSensor

“IBM WebSphere Message Broker sensor” on page81

MBServerSensor

“IBM WebSphere MQ Server sensor” on page 83 MQServerSensor

“IBM WebSphere sensor” on page 61 • WebSphereCellSensor• WebSphereNodeSensor• WebSphereVersionSensor

“IP device sensor” on page 222 IpDeviceSensor




“iPlanet server sensor” on page 86 IPlanetServerSensor

“IPSO computer system sensor” on page 321 IPSOComputerSystemSensor

“JBoss Application Server 7 sensor” on page 89 JBoss7Sensor

“JBoss server sensor” on page 86 • JBossSensor• JBossVersionSensor

“Kernel-based virtual machine sensor” on page93

KvmSensor

“LAN Manager SNMP sensor” on page 277 LanManagerSnmpSensor

“LDAP sensor” on page 278 LdapSensor


“Microsoft Cluster sensor” on page 94 MSClusterSensor

“Microsoft Exchange 2003 sensor” on page 108 Exchange2003Sensor

“Microsoft Exchange sensor” on page 97 ExchangeSensor

“Microsoft HyperV sensor” on page 113 Microsoft HyperV Sensor

“Microsoft IIS Web server sensor” on page 114 • IISWebServiceSensor• IISServerSensor

“Microsoft SQL Server sensor” on page 181 SqlServerSensor

“NetApp sensor” on page 408 NetAppSensor

“NetScreen SNMP sensor” on page 281 NetscreenSnmpSensor

“NFS sensor” on page 120 NFSServerSensor

“Nokia SNMP sensor” on page 282 NokiaSnmpSensor

“OpenVMS computer system sensor” on page 330 OpenVmsComputerSystemSensor

“Oracle Application Server sensor” on page 122 • OracleAppOpmnSensor• OracleAppSensor

“Oracle sensor” on page 186 OracleSensor


“PIX sensor” on page 283 PixSensor


“SAP CCMS server sensor” on page 126 CCMSServerSensor

“SAP SLD server sensor” on page 130 SLDServerSensor


“SMB server sensor” on page 134 SMBServerSensor

“SMS server sensor” on page 135 SMSServerSensor

“Snap Drive sensor” on page 409 SnapDriveSensor




“SNMP MIB2 sensor” on page 286 SnmpMib2Sensor


“Solaris zones generic sensor” on page 229 ZonesGenericSensor

“Storage sensor” on page 410 StorageSensor

“Sybase IQ sensor” on page 203 SybaseIQSensor

“Sybase sensor” on page 196 SybaseSensor

“Sun Fire SysControl sensor” on page 340 SysControlSensor

Sun Sparc Virtualization sensor SunSparcVirtualizationSensor

SVC Storage sensor SVCStorageSensor

“Tru64 computer system sensor” on page 342 Tru64ComputerSystemSensor

“Veritas cluster sensor” on page 138 VeritasClusterSensor

“Veritas Storage Foundation sensor” on page 414 VeritasStorageSensor

“VMware ESX computer system sensor” on page344

VmwareComputerSystemSensor

“VMware ESXi computer system sensor” on page349

VmwareEsxiComputerSystemSensor

“VMware Virtual Center server sensor” on page140

VirtualCenterSensor

“WebLogic SSH sensor” on page 159 • WeblogicLauncherSensor• WeblogicApplicationSensor• WeblogicDomainSensor• WeblogicServerSensor


“WPAR generic sensor” on page 237 WparGenericSensor

XIV Storage sensor XIVStorageSensor

“zEnterprise sensor” on page 238 ZEnterpriseSensor

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

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


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



“IBM Tivoli Utilization sensor” on page 215 OperatingSystemUtilizationSensor



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




Sensors that support a non-admin discovery on Windows operating systemThese sensors support discovery on the Windows operating system without providing user credentialswith the administrator role.

The following sensors now support discovery on Windows without providing user credentials with theadministrator role:Application sensors

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


“DNS sensor” on page 34 DnsSensor

“NFS sensor” on page 120 NFSServerSensor

“SMB server sensor” on page 134 SMBServerSensor

Database sensors

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


“Microsoft SQL Server sensor” on page 181 SqlServerSensor

Generic sensors

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


“Custom application server sensor” on page 207(with restrictions)

CustomAppServerSensor


“Generic server sensor” on page 212 (withrestrictions)

GenericServerSensor



“Session sensor” on page 226 (with restrictions) SessionSensor

Operating system sensors

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


“Windows computer system sensor” on page352

WindowsComputerSystemSensor


Restrictions:

• Session sensor does not support automatic deployment of TADDM WMI provider files. See “Copyingthe TaddmWmi files” on page 362.

• Generic server sensor does not discover runtime process command-line arguments. Therefore, theCustom application server sensor does not start for the templates that are based on the Argumenttype conditions. Also, any application sensors that use such templates might not start.

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

The rest of the application sensors still require the user to have an administrator role for successfuldiscovery.

Note: Windows User Access Control (UAC) settings do not affect non-admin discovery because theycannot be disabled for standard users.

Configuring the sensors to run a non-admin discoveryTo configure the sensors to run a non-admin discovery on the Windows operating system, see the“Configuring for a non-admin Windows discovery” on page 360 topic.

Sensors that support script-based and asynchronous discoverySome sensors can be run as script-based sensors. These sensors are more apparent, which means thatall commands that the sensor uses are in one script, which you can view. Script-based sensors alsosupport asynchronous discovery.

The following table lists all script-based sensors, and the operating systems, on which they aresupported.

The “Asynchronous discovery sensor” on page 206 is required for asynchronous discovery. See also theConfiguring for asynchronous discovery topic in the TADDM Administrator's Guide.

Notes:

• Some of the following sensors are script-based by default, but some of them must be configured forscript-based discovery. See the Configuring for script-based discovery topic in the TADDMAdministrator's Guide.

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

Table 9. List of script-based sensors.

Sensor Sensor name that is used inthe UI and logs

The operating systems, onwhich the sensor issupported

Script-based bydefault

“Apache sensor” on page16

ApacheServerSensor • AIX• Linux• Solaris

No

“Asynchronous discoverysensor” on page 206

ASDSensor • AIX• FreeBSD• Linux• HP NonStop• Solaris• Windows

Yes


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




“Citrix XenServer sensor” onpage 290

XenServerSensor • Linux Yes

“FreeBSD computer systemsensor” on page 294

FreeBSDComputerSystemSensor

• FreeBSD No

“Generic server sensor” onpage 212

GenericServerSensor • AIX• Linux• Solaris• Windows

No

“HP NonStop computersystem sensor” on page 300

HpNonStopComputerSystemSensor

• HP NonStop Yes

“IBM AIX computer systemsensor” on page 306

AixComputerSystemSensor

• AIX No

“IBM DB2 sensor” on page173

Db2Sensor • AIX• Linux• Solaris

No

“IBM Lotus Domino serversensor” on page 45

DominoInitialSensor • AIX• Linux• Solaris

No

“IBM Tivoli Utilizationsensor” on page 215

OperatingSystemUtilizationSensor

• AIX• FreeBSD• Linux• Solaris

No

“IBM WebSphere MQ Serversensor” on page 83

MQServerSensor • AIX• Linux• Solaris• Windows

Yes

“IBM WebSphere sensor” onpage 61

WebSphereScriptSensor

• AIX• Linux• Solaris

• Windows

Yes

“JBoss Application Server 7sensor” on page 89

JBoss7Sensor • AIX• Linux• Solaris• Windows

Yes


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




“Kernel-based virtualmachine sensor” on page93

KVMSensor • Linux Yes

“Linux computer systemsensor” on page 322

LinuxComputerSystemSensor

• Linux No

“Microsoft Exchange sensor”on page 97

ExchangeSensor • Windows Yes

“Microsoft IIS Web serversensor” on page 114

IISServerSensor • Windows Yes

“Microsoft SQL Serversensor” on page 181 (withrestrictions)

SqlServerSensor • Windows No

“Oracle sensor” on page 186 OracleSensor • AIX• Linux• Solaris

No

“Solaris computer systemsensor” on page 332

SunSparcComputerSystemSensor

• Solaris No

“Sun Sparc Virtualizationsensor” on page 338

SunSparcVirtualizationSensor

• Solaris Yes

“WebLogic SSH sensor” onpage 159

WeblogicLauncherSensor

• AIX• Linux• Solaris

No

“Windows computer systemsensor” on page 352

WindowsComputerSystemSensor

• Windows No

Restrictions

• The script-based discovery mode of the Microsoft SQL Server sensor relies on the sqlpsmodule, which is available in Microsoft SQL Server 2008, and later. Therefore, if you want todiscover Microsoft SQL Server 2005, you must have other instances like Microsoft SQL Server 2008,2008 R2, or 2012 installed as well.

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

New integration methodImportant: Starting with the TADDM 7.3.0, it is advised to integrate with IBM Tivoli Monitoring 6.3 usingOSLC Automation. The old method of integration with the use of IBM Tivoli Monitoring Scope sensor isdeprecated and will be removed from future releases.

Learn more about TADDM integration with ITM by using OSLC Automation from the Integrating TADDMwith IBM Tivoli Monitoring via OSLC Automation topic of the TADDM Administrator's Guide and about


sensors that support discovery using OSLC Automation at “Sensors that support discovery using OSLCAutomation ” on page 13.

The “IBM Tivoli Monitoring Scope sensor” on page 48 is required for discovery using IBM TivoliMonitoring. This sensor must be run at least once to create the necessary scope sets.

The IBM Tivoli Monitoring Scope sensor creates scope sets for all active computer systems in a TivoliMonitoring environment. After these scope sets are created, you can run Level 2 and Level 3 discovery ofthose computer systems using a Tivoli Monitoring session, without including the IBM Tivoli MonitoringScope 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 reachablefrom TADDM discovery server), you might need to include the IBM Tivoli Monitoring Scope sensor in yourprofile with startSessionOnly option enabled. For details, see Configuring the discovery profile in IBMTivoli Monitoring Scope sensor documentation.

For Level 2 and Level 3 discovery of the systems that are monitored by IBM Tivoli Monitoring, thefollowing features must be installed on the target system:

• On Windows target systems, Microsoft .NET Framework must be installed. For more information, seethe Configuring for discovery of Windows systems topic in the TADDM Administrator's Guide.

• On Linux and UNIX target systems, uuencode and uudecode commands that are compliant with thePortable 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 10on page 12 lists the sensors that support discovery using Tivoli Monitoring. When a sensor runs withinthe Tivoli Monitoring session, it uses the Tivoli Monitoring access credentials rather than the accesscredentials that are configured for the sensor. The Tivoli Monitoring user account must have necessaryauthorization to access the application that is being discovered. For example, to discover IBM DB2Universal Database (UDB) servers, the Tivoli Monitoring user account on the target DB2 server must be amember of the DB2 administration group.

Table 10. Sensors that support discovery using IBM Tivoli Monitoring





“IBM DB2 sensor” on page 173 Db2Sensor


“IBM WebSphere sensor” on page 61 WebSphereScriptSensor




“Sun Sparc Virtualization sensor” on page 338 SunSparcVirtualizationSensor


“WebLogic SSH sensor” on page 159 WeblogicLauncherSensor



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

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

To learn more about configuring the discovery, see the Configuring for discovery over OSLC AutomationSession topic in the TADDM Administrator's Guide.

For Level 2 and Level 3 discovery of the systems that are monitored by IBM Tivoli Monitoring, theMicrosoft .NET Framework must be installed on the Windows target systems.

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

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

Table 11. Sensors that support discovery using OSLC Automation.





“IBM DB2 sensor” on page 173 Db2Sensor


“IBM WebSphere sensor” on page 61 WebSphereScriptSensor




“Sun Sparc Virtualization sensor” on page 338 SunSparcVirtualizationSensor


“WebLogic SSH sensor” on page 159 WeblogicLauncherSensor


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

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

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

Ensure that the following prerequisites for discovering Linux, Solaris, AIX, and Linux on System zoperating systems have been met:

• Create a service account. Configure the account to be a member of the sys group, and use /bin/shas the shell for this account.

• Install and test the Secure Shell (SSH) protocol from the TADDM server. If you are using key-basedauthentication, install public keys on all the hosts. To verify that the login and password or the key


and passphrase work properly, enter the ssh command from the command prompt on the computerwhere the TADDM server is installed.

• Install the LiSt Open Files (lsof) program on all host computers according to the requirements in lsofrequirements in the TADDM Wiki at https://github.com/TADDM/taddm-wiki/wiki/Generic-Server-Sensor-(lsof).

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

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

SolutionAccess to the sudo command must be configured so that the TADDM user, which is the user thatstarts the TADDM server, can run sudo commands without having the password prompt displayed. Toconfigure 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/binsh ./stop-local-anchors.sh

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

A discovery of application servers that are running on the Solaris 10 operatingsystem returns incorrect port numbersProblem

Incorrect port numbers are returned when you run a discovery of application servers that are runningon the Solaris 10 operating system.

SolutionEnsure that lsof 4.77, or later, is installed on every system that is running on the Solaris 10 operatingsystem. Versions of lsof prior to 4.77 do not support Solaris 10 6/06 or later. Additionally, there aretwo version of lsof 4.77. One is for the pre 6/06 Solaris 10 release, and the other is for the 6/06Solaris 10 release, and later versions. Make sure that you install the version of lsof 4.77 that matchesthe version of the Solaris 10 Operating System that is installed.

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

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

Sensor name that is used in the GUI and logsActiveDirectorySensor


https://github.com/TADDM/taddm-wiki/wiki/Generic-Server-Sensor-(lsof)

https://github.com/TADDM/taddm-wiki/wiki/Generic-Server-Sensor-(lsof)

Security issuesThe sensor uses the command ntdsutil.exe during the discovery and this command requires elevatedsecurity privileges. To verify that the discovery account has adequate privileges, enter the followingcommand on one line:On Windows 2000 and Windows Server 2003:

ntdsutil "domain management" connections "connect to server localhost" q "list" q q

On Windows Sever 2008:

ntdsutil "partition management" connections "connect to server localhost" q "list" q q

Model objects with associated attributesThe Active Directory sensor creates model objects with associated attributes. The attributes indicate thetype of information that the sensor collects about Microsoft Active Directory servers in your ITenvironment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.sys.ActiveDirectory

• Host• InitRecvTimeout• MaxConnIdleTime• MaxConnections• MaxDatagramRecv• MaxNotificationPerConn• MaxPageSize• MaxPoolThreads• MaxQueryDuration• MaxReceiveBuffer• MaxResultSetSize• MaxTempTableSize• MaxValRange• NamingContexts• Name• RootDomain• SchemaVersion• ServiceXML• WorkingDirectory

sys.ServiceAccessPoint

• ContextIp• BindAddress• Name• ProductName• ProductVersion• VendorName


sys.NamingContext

• Index• Value

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

Configuring the scopeThe Active Directory server must be included in the discovery scope.

Configuring the access listYou must add the computer system (for example, Windows) to the access list, and the user ID foraccessing the system must belong to the administrators group.

Configuring the discovery profileThe sensor is enabled by default in a Level 3 discovery profile. Alternatively, you can create a customprofile and enable the Active Directory sensor and the Windows computer system sensor from the newprofile.

Apache sensorThe Apache sensor discovers Apache Web servers.

Sensor name that is used in the GUI and logsApacheServerSensor

PrerequisitesThe TADDM service account requires:

• Execute permissions on the httpd binary file• Read access to the httpd.conf file• Discovery user shall have Read and execute permissions for all the required Apache libraries/modules/files/folders to run httpd command successfully (for e.g: /oracle/product/iasgrm/librarypath and /oracle/product/iasgrm/Apache, and so on).

LimitationsThe Apache sensor cannot discover the Apache server if the Apache server instance is configured orstarted in such a way that it rewrites its command line (for example, rewrites the argv array), causing theApache server instance to show in a process listing as httpd, without any path or command-line options.

Model objects createdThe sensor creates the following model objects:

• app.AppConfig• app.CertificateFile• app.ConfigFile• app.PrivateKeyFile• app.web.ServerAlias


• app.web.apache.ApacheGlobalSSLSettings• app.web.apache.ApacheModule• app.web.apache.ApacheSSLSettings• app.web.apache.ApacheServer• app.web.apache.ApacheVirtualHost• app.web.apache.ApacheWebContainer• app.web.ibm.IBMHTTPServer• app.web.oracleapp.OracleAppHTTPServer• app.web.WebConnection• app.web.WebVirtualHostConfigDirective

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

Sensor configuration requirementsFor asynchronous discovery, the sensor requires no configuration.

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

Access list configuration requirementsFor asynchronous discovery, the access list is not used.

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

LimitationsSome function that is provided by the Apache sensor during a nonscript-based discovery is not supportedin an asynchronous or script-based discovery.

Application descriptor discovery is not supported.

The following attributes are not supported for a configuration file:

• Last modified• Owner• Group• Permissions

Only running applications are discovered.


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

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

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

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


com.collation.discover.agent.ApacheServerAgent.UseListenningIp=falseThe sensor discovers Apache Web servers and assigns the same name instead of reporting one foreach Web server host name. When this property is set to true, the display name for the ApacheServerobject is set to:HOSTNAME:LISTENINGIP:PORTThe default value of this property is false.You must manually delete the HOSTNAME:PORT instances.

com.collation.discover.agent.ApacheServerAgent.CmdPrefixAdds a command or script that must be run before the httpd -V command. This property can beconfigured for the operating system name, IP address or both.The Apache sensor attempts to use the property if the first (standard) command fails. For example:com.collation.discover.agent.ApacheServerAgent.CmdPrefix. AIX.9.156.47.172=LIBPATH=/usr/local/apache2/build:/usr/local/ apache2/lib:/usr/lib:/lib/;export LIBPATH

Troubleshooting the sensorThis topic describes common problems that occur with the Apache sensor and presents solutions forthose problems.

Discovery error with "cannot execute httpd"Problem

A discovery error states cannot execute httpd, but the TADDM service account can run the httpdprocess manually.

The session sensor tries each appropriate access list credential until one works. When one access listcredential works, the session sensor stops trying. Therefore, the first access list credential that worksmust be able to run the httpd process.

SolutionTry using scope restrictions with a reordered access list to force the correct account to be used todiscover the Apache server.

Apache sensor fails with error CTJTD0072EProblem

The Apache sensor uses the httpd -V command to get the root directory, configuration file, and otherinformation related to the Apache server. If the httpd -V command fails, the sensor also fails.

SolutionUse the com.collation.discover.agent.ApacheServerAgent.CmdPrefix property to specify a commandto run before the httpd -V command is run.

Many fields in the Details panel are emptyProblem

A number of fields in the Details panel are empty.Solution

The service account cannot read the http.conf file. Make the http.conf file publicly readable, oradd the service account to a group that has read access to the http.conf file.


Citrix server sensorThe Citrix server sensor discovers a Citrix Presentation Server (Citrix Presentation Server Enterprise 3 and4) or XenApp server (Citrix XenApp Enterprise version 5 and version 6).

Sensor name that is used in the GUI and logsCitrixServerSensor

Security issuesThe discovery user must have read permissions (defined in the Citrix Product console) for the Citrixconfiguration. To discover the Citrix Presentation Server configuration, you must have permission to querythe 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. Itis a part of the Citrix product.

To grant this permission, complete the following steps:

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

permission that must be granted to query the Citrix WMI provider.

a. Select a user or group.b. Click Editc. Select the appropriate permission:

• View only: works for the Citrix sensor• Full administration: works for the Citrix sensor• Custom: the administrator can define their own access level

Model objects with associated attributes

The Citrix server sensor creates model objects with associated attributes. The attributes indicate the typeof information that the sensor collects about Citrix Presentation Server and XenApp server in your ITenvironment.

Troubleshooting the sensor

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

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

Model objects with associated attributesThe Citrix server sensor creates model objects with associated attributes. The attributes indicate the typeof information that the sensor collects about Citrix Presentation Server and XenApp server in your ITenvironment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.CitrixAccountAuthority

• AuthorityName• AuthorityType


• Group

CitrixAppFolder

• Applications• Farm

CitrixApplication

• AppFolder• ApplicationID• CitrixFarm• CitrixGroups• Servers• Users

CitrixFarm

• AppFolders• DSDriver• DSODBC• FarmName• LicensePool• LocalIp• SNMPDisconnectTrap• SNMPLogoffTrap• SNMPLogonTrap• SNMPThresholdExceededTrap• SNMPThresholdValue• ServerFolders• Zones

CitrixFolder

• FolderDN• FolderName• Folders• Parent

CitrixGroup

• AccountAuthority• CitrixApplications

CitrixLicense

• Pool• SerialNumber

CitrixLicensePool

• DupGroup• Farm• FloatOk• HostBased• HostID


• Licenses• PLD• Platforms• SubscriptionDate• UserBased• VendorString

CitrixServer

• Applications• Folder• IsFarmServer• LocalPrimarySAP• Processes• Zone

CitrixServerFolder

• Farm• Servers

CitrixUser

• AccountAuthority• Applications

CitrixZone

• DataCollector• Farm• Servers• ZoneName

Troubleshooting the sensorThis topic describes common problems that occur with the Citrix server sensor and presents solutions forthose problems.

The Citrix sensor runs slowlyProblem

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

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

• com.collation.discover.agent.CitrixServerAgent.sessiontimeout=600000

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

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


Citrix 7 server sensorThe Citrix 7 server sensor discovers a XenApp server (Citrix XenApp Enterprise version 7.6) and it usesCitrix powershell SDK interface for discovery purpose.

Sensor name that is used in the GUI and logsCitrix7Sensor

Elements discovered by the sensorThe sensor discovers the following elements that are associated with Citrix XenApp applicationvirtualization software environment:

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

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

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

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

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

Licensing Information – Citrix License pools and individual license details.

PrerequisitesThe following prerequisites are required:

• This script-based sensor uses the same discovery user that is used for Windows logon.• The Windows discovery user must have “administrator read only” permissions (defined in the Citrix

console) for the Citrix configuration on any delivery controller for each site. Citrix requires that thediscovery user be an active directory account and not a local account.

• Citrix Powershell snap-ins shall be installed and available on Delivery Controller.

Model objects with associated attributesCitrix 7 introduces an architecture change from Citrix 6, but the TADDM data model is based on Citrix 6architecture. In order to preserve backwards compatibility for business application mapping, the Citrix 7architecture components are stored as Citrix 6 data model components. The table below shows the oldand new concepts and how they map to the TADDM data model.

Table 12. Citrix 7 to Citrix 6 mapping

Citrix 7 Citrix 6 Comments

Site CitrixFarm/CitrixZone For each Citrix Site there will be aone-to-one Farm/Zonecombination with the samename.

Admin Folder CitrixAppFolder Organizes the CitrixApplicationcomponents.

Desktop Catalog CitrixServerFolder NA

Desktop Group NA Desktop Groups are used toassign CitrixApplications toCitrixServers.


The Citrix 7 server sensor creates model objects with associated attributes. The attributes indicate thetype of information that the sensor collects about Citrix Presentation Server and XenApp server in youranIT environment.

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

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

CitrixAccountAuthority

• AuthorityName• Group

CitrixAppFolder

• Applications• Farm

CitrixApplication

• AppFolder• ApplicationID• CitrixFarm• CitrixGroups• Servers• Users

CitrixFarm

• AppFolders• FarmName• LicensePool• LocalIp• ServerFolders• Zones

CitrixFolder

• FolderDN• FolderName• Folders• Parent

CitrixGroup

• AccountAuthority• CitrixApplications

CitrixLicense

• Pool• SerialNumber

CitrixLicensePool

• DupGroup• Farm


• FloatOk• HostBased• HostID• Licenses• PLD• Platforms• SubscriptionDate• UserBased• VendorString

CitrixServer

• Applications• Folder• LocalPrimarySAP• Processes• Zone

CitrixServerFolder

• Farm• Servers

CitrixUser

• AccountAuthority• Applications

CitrixZone

• DataCollector• Farm• Servers• ZoneName

Limitations• Site names are assumed to be global. We cannot have two sites with the exact same name or this will

cause over-merging.• Asynchronous Discovery mode is not supported.

Note: For Anchor based discovery of Citrix XenApp 7.6, script discovery needs to be enabled incollation.properties file:

com.ibm.cdb.discover.PreferScriptDiscovery=true

Docker Host sensorThe Docker Host Sensor (DHS) discovers Docker Hosts, host attributes, containers, networking, image andstorage related information.

Sensor name that is used in the GUI and logsDockerHostSensor


Elements discovered by the sensorThe sensor discovers the following elements:

• Docker Hosts• Docker Containers• Docker Volumes• Docker Networks• Dockers Images

In the Discovery Management Console and Data Management Portal, a Docker Host is represented by ablue-colored Docker whale design icon, and, Docker container using square shaped four-stacked shippingcontainers.

The Docker Host Sensor uses REST APIs to retrieve the discovery related information from the Dockerhost machine running the 'dockerd' daemon process/application. The retrieved data primarily comprisesof attribute data that is required to match naming rules and create valid model objects.

Prerequisites• The Docker daemon/application is running on a target Linux machine• For successful discovery of Docker Host, REST support must be enabled on the target machine• Ports for web service communication must be defined. By default, port value resulting from

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

• Single set of TLS certificate is applicable for TADDMs communication to all the Docker Host• Enable or Disable of TLS for discovery will have a uniform behavior across ALL Docker hosts defined

within the scope

– Either applicable to ALL, or, NONE Docker Hosts

In the Discovery Management Console and Data Management Portal, a Docker Host is represented by ablue-colored Docker whale design icon, and, Docker container using square shaped four-stacked shippingcontainers.

The Docker Host Sensor uses REST APIs to retrieve the discovery related information from the Dockerhost machine running the 'dockerd' daemon process/application. The retrieved data primarily comprisesof attribute data that is required to match naming rules and create valid model objects.

Security issuesNo specific access-list entry is required. For TLS based security details, see Connection to Docker Hostbelow:

Connection to Docker HostThe Docker Host Sensor can discover data from Docker Host through 2 modes: non-TLS mode, and, TLSmode.

Non-TLS mode

The non-TLS mode is the default mode. It retrieves data via web services and doesn’t requireauthentication. This mode is recommended in private network, or, private cloud deployments in customerpremises.

TLS mode

The TLS mode is secure mode of communicating with the Docker Host. It verifies the TLS certificatesinstalled in TADDM and target Docker Host. To use this mode, you must set the enableTLS property to


true, along with configuring the certificate paths defined in discovery profile. For details, see 'Configuringthe discovery profile'. For manually generating the TLS certificates for TADDM and Docker host, see'Manual TLS certificate generation for non UCP'.

Model objects with associated attributesThe Docker Host Sensor creates model objects with associated attributes. The attributes indicate the typeof information that the sensor collects about Docker Host resources in your IT environment.


app.docker.dockerhost.DockerHost

• Name• VersionString• DockerContainers• DockerImages• DockerNetworks• DockerVolumes• Host• XA

o Architecture

o KernelVersion

o OperatingSystem

o OSType

o RunningContainers

o StoppedContainers

o TotalContainers

app.docker.dockerhost.DockerContainer

• Name• Parent• RuntimeProcesses• DockerContainerStatus• DockerImages• DockerNetworks• DockerVolumes

app.docker.dockerhost.DockerImage

• DockerHost• ImageName• DockerContainer

app.docker.dockerhost.DockerNetwork

• Name• SubnetAddress• DockerHost• DockerContainer


app.docker.dockerhost.DockerVolume

• Name• DockerHost• DockerContainer

sys.RuntimeProcess (applicable to processes within a container)

• PID• Command• PPID• User• CmdLine (refers to the full command)

Configuring the sensorBefore using the Docker Host Sensor, you must configure it.

Configuring the discovery profile:

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

To create the discovery profile, complete the following steps:Example:

1. In the Discovery drawer of the Discovery Management Console, click Discovery Profiles.2. In the Discovery Profiles window, click New.3. In the Create New Profile window, type the profile name and description. From the Clone existing

profile list, select Level 3 Discovery and click OK4. On the Sensor Configuration tab, select the DockerHostSensor sensor and click New.5. In the Create Configuration window, type the name and description for your configuration, and

select the Enable Configuration check box.6. In the Configuration section of the Create Configuration window, click

discoverNonRunningContainers. Then, double-click the Value field in the row, and type false.7. Click OK to return to the Discovery Profiles window.8. In the Discovery Profiles window, click Save.

PropertiesYou can modify the following properties and attributes:

portList

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

enableTLS

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

The default value is false.

pathStore

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


caFileName

Certificate Authority file name.

cerFileName

Client certificate file name

keyFileName

Client key file name

Enable REST support on Docker HostOn a Docker Host following configuration changes need to be done:

1. Enable the REST APIs on Docker host.

• Login to the Docker host machine using 'root' credentials.• Create/Update the following file on Docker Host:

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

with following content:

[Service]

ExecStart=

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

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

service docker restart

ps -aef | grep -i dockerd

Manual TLS certificate generation for non UCPIn case TLS mode is enabled and certificates are not available, you can manually generate thesecertificates in a Linux machine as below.

A. Docker Host:

On Docker host machine, generate CA private and public keys per the stepwise procedure mentionedbelow. Remember the key sample below is for example, and you must provision per your securitystandards.

1. Login to the Docker Host machine using 'root', or, another user having 'super-user' privileges.2. Make a local directory via commands.

mkdir docker_certificates

cd docker_certificates

3. Execute command:

a. openssl genrsa -aes256 -out ca-key.pem 4096

• 1. Enter any pass phrase for generating ca-key.pem and store it safely

b. openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem


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

4. Using the CA, create a server key and certificate signing request (CSR) via commands

a. openssl genrsa -out server-key.pem 4096

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

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

when creating the certificate via command:

a. echo subjectAltName = DNS:$HOST,IP:<DockerHost-IP> > extfile.cnf

• 1. where, $HOST is hostname of the Docker Host.

a.echo extendedKeyUsage = serverAuth >> extfile.cnf

6. Now, generate the key via command:

a.openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem \

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

• 1. Enter the password provided in step (3.a.1).7. Remove unnecessary files and set the permissions correctly:

rm -v server.csr

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

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

8. Start the Docker daemon using TLS verfication:

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

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

B. TADDM Machine

TLS client certificates for TADDM machine (corresponding to the ones generated for Docker Host) can begenerated manually. On the TADDM host machine, generate CA private and public keys by following thestepwise procedure mentioned below:

1. Login to the TADDM machine using 'root' user credentials2. Make a local directory via commands

a. mkdir taddm_certificates

b. cd taddm_certificates

3. Using the CA, create a server key and certificate signing request (CSR) via commands:

a. openssl genrsa -out key.pem 4096


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

c. echo extendedKeyUsage = clientAuth >> extfile.cnf

4. Sign the private key via command:

a. openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf

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

5. Remove unnecessary files and set the permissions correctly:

a. rm -v client.csr

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

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

d. cd ../

e. chown -R taddmusr:taddmusr taddm_certificates

f. chown -R taddmusr:taddmusr taddm_certificates

6. Validate the TLS connection with DockerHost machine using the following commands:

curl https://<Dockerhost-IP>:<Docker-Port>/_ping --cert ./cert.pem --key key.pem --cacert ca.pem

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

Manual TLS certificate generation for UCP

1. Login to the TADDM machine using 'root' user credentials.2. Make a local directory via commands:

a. mkdir taddm_certificates

b. cd taddm_certificates

3. Validate the UCP url. It should up and running. For example: https://x.x.x.x:4434. Login to Docker UCP user interface.5. Download the certificates from UCP user interface:

• Navigate to admin > My Profile > Client Bundles > New Client Bundle > Generate Client Bundle.6. Download the certificates zip file.7. Copy the certificates zip file to TADDM server in taddm_certificates directory created in step 2.8. Unzip the certificates zip file to TADDM server in taddm_certificates directory.9. Run the below command to change an ownership of TADDM certificates:

chown -R taddmusr:taddmusr taddm_certificates


https://x.x.x.x:443

Troubleshooting the sensorThis topic describes common problems that occur with the Docker Host sensor and presents solutions forthose problems.

The sensor fails with description ` CTJTD1585E Error – Docker host is not reachable on any of theseports:`

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

SolutionValidate using 'ps - eaf | grep dockerd' to see which port is used by 'dockerd' daemon process.The output should look something like below:

/usr/bin/dockerd -H tcp://9.158.143.51:2376 -H unix:///var/run/docker.sock

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

The sensor fails with description `CTJTD1587E/ CTJTD1590E Error – TLS configuration mismatchbetween Docker Host sensor and remote node:’

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

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

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

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

Solution : Check for existence of the configured pathstore directory on the TADDM discovery server. If thedirectory exists, validate that it has been granted correct permissions.

drwxr-xr-x. 2 taddmusr taddmusr 4096 Nov 24 08:28 taddm_certificates

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

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

Solution : If dockerd process/application is running good, it becomes important to validate the specificport on which the daemon/process is listening using the command ps - Aef | grep dockerd. The portobtained from output must match with the one TADDM is trying to connect.

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

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

Solution : Validate for any missing Java jars and place the corresponding one in the below directory:

/opt/IBM/taddm/dist/lib/jdbc

Run discovery again.

Docker Swarm Cluster sensor

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

Sensor name that is used in the GUI and logs

DockerSwarmClusterSensor


Elements discovered by the sensor

The sensor discovers the following elements:

• Docker Swarm• Docker Nodes (referred as Docker Host)• Docker Services• Docker Network

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

The Docker Swarm cluster sensor uses REST APIs to retrieve the discovery related information from theDocker host ‘Manager’ node running the 'dockerd' daemon process/application in ‘Manager’ role. Theretrieved data primarily comprises of attribute data that is required to match naming rules and createvalid model objects.

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

machine.• To trigger DSCS, at-least ONE Docker Host in 'Manager' role must be included in the discovery scope.• At any given time, a given Docker Host may belong to a single swarm cluster ONLY, i.e. it cannot be part

of multiple Docker swarm clusters simultaneously.• Docker swarm cluster sensor is in turn dependent on the discovery performed by Docker Host sensor.

Vis-a-vis, configuration for Docker Swarm Cluster sensor is implicitly derived from Docker Host sensor.For details, see 'Docker Host Sensor'“Docker Host sensor” on page 24.

• Single set of TLS certificate is applicable for TADDMs communication to all the Docker Host.• Enable or Disable of TLS for discovery will have a uniform behavior across ALL Docker hosts defined

within the scope.

o Either applicable to ALL, or, NONE Docker Hosts.

Security issues• No specific access-list entry is required. For TLS based security details, see “Connection to Docker

Swarm” below:

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

Non-TLS mode

The non-TLS mode is the default mode. It retrieves data via web services and doesn’t requireauthentication. This mode is recommended in private network, or, private cloud deployments in customerpremises.

TLS mode

The TLS mode is secure mode of communicating with the Docker Host. It verifies the TLS certificatesinstalled in TADDM and target Docker Host. To use this mode, you must set the enableTLS property totrue, along with configuring the certificate paths defined in discovery profile. For details, see “Docker HostSensor: Configuring the discovery profile” . For manually generating the TLS certificates for TADDM andDocker host, see “Docker Host sensor” on page 24 'Configuring the discovery profile'. For manuallygenerating the TLS certificates for TADDM and Docker host, see “Docker Host sensor” on page 24 ':Manual TLS certificate generation'.


Model objects with associated attributesThe Docker Swarm Cluster Sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about Docker Swarm resources in your ITenvironment.


app.docker.dockerswarm.DockerSwarm

• app.docker.dockerswarm.DockerSwarm• Servers• SwarmServices• IP• Port• DockerNetwork

app.docker.dockerswarm.SwarmService

• Name• DockerSwarm

app.docker.dockerhost.DockerContainer

• Task• SwarmService

app.docker.dockerhost.DockerNetwork

• Name• SubnetAddress• DockerHost• DockerContainer

Note: All the Docker Host Sensor model objects are also applicable here, since Docker Swarm is a clusterof Docker Host nodes.

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

Configuring the discovery profile:

Docker swarm cluster sensor is in turn dependent on the discovery performed by Docker Host sensor. Vis-a-vis, configuration for Docker Swarm Cluster sensor is implicitly derived from Docker Host sensor. Fordetails, see “Docker Host sensor” on page 24 :'Configuring the Sensor Profile'.

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

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

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

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

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

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


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

Sensor name that is used in the GUI and logsDnsSensor

Model objects createdThe sensor creates the following model object:

• Sys.DNSSAP

Troubleshooting the sensorThis topic describes common problems that occur with the DNS sensor and presents solutions for thoseproblems.

Sensor fails to discover a DNS serverProblem

The sensor is unable to discover a running DNS server.Solution

If the sensor fails to discover a DNS server, verify that the DNS server can resolve IP address127.0.0.1. The DNS sensor requires the DNS server to resolve 127.0.0.1 and, if the DNS server doesnot return a value, the sensor fails to recognize the particular DNS server.

HIS sensorThe HIS sensor discovers a Microsoft Host Integration Server.

Sensor name that is used in the GUI and logsHISServerSensor

PrerequisitesBefore you run this sensor, the following prerequisites must be met:

• The discovery of the Windows Computer System must succeed.• The SNABase service must be running.• Using the TADDM Windows Management Instrumentation (WMI) provider, WMI read access to theroot/microsoftHis namespace must be granted. If the discovery of the Windows Computer Systemsucceeded, this WMI read access is granted by default. Administrative-level access is preferable.

Model objects with associated attributesThe HIS sensor creates model objects with associated attributes. The attributes indicate the type ofinformation that the sensor collects about Microsoft Host Integration Server resources in your ITenvironment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.app.his.HISDomain

• APPCModes• AuditLevel• BroadcastMeanTime


• BroadcastProtocolIpxSpx• BroadcastProtocolNamedPipes• BroadcastProtocolTcpIp• ClientBackupDomainNames• ClientBackupSponsorNames• ClientDomainBackupType• ConfigServer• DisplayName• DisplayVerbConnection• DomainName• EventLogServerName• NetViewConnection• PopupServerName• RTMEndOfSession• RTMOverflow• RTMThreshold• RTMTimerUntil• Security3270• SecurityAPPC• SecurityLUA• Servers• Status

app.his.HostIntegrationServer

• DisplayName• Domain• LinkServices• Name• ProductName• ProductVersion• ServerRole• Services• TransportString• VendorName

app.his.IPDLCService

• BackupNetworkNameServers• CMDMaxRetry• CPName• DeviceDriver• DisplayName• DllName• IsRemotable• LENNode• LocalAddressAdapter


• LocalAddressIP• MaxActivationAttempts• MaxBTUReceive• MaxBTUSend• Name• Network• NodeID• Parent• PrimaryNetworkNameServer• ReceiveAckTimeout• ResolvedIP• UseDynamicPUDefinition

app.his.APPCMode

• AllowLZandRLE• AutoActivate• DisplayName• EndPointOnly• IsPriority• MaxReceiveCompression• MaxSendCompression• MinimumContentionWinnerLimit• Name• Parent• PartnerMinimumContentionWinnerLimit• ReceivePacing• ReceiveRuSize• SessionLimit• TransmitPacing• TransmitRuSize

app.his.HISConnection

• Activation• AllowIncoming• BlockId• CompressionLevel• DisplayName• DynamicLuDef• LUs• LinkService• Name• NodeId• Parent• PartnerConnectionName• PeerRole


• RemoteBlockId• RemoteControlPoint• RemoteEnd• RemoteNetName• RemoteNodeId• RetryDelay• RetryLimit• XIDFormat

app.his.HISLUA

• Compression• DisplayName• HighPriorityMode• Name• Number• Parent• Protocol• UserWksSecure

app.his.HISLUDisplay

• AssociatedLU• Compression• DisplayModel• DisplayModelOverride• DisplayName• HISService• Name• Number• Parent• Protocol• UserWksSecure

app.his.HISLUPrint

• AssociatedLU• Compression• HISService• Name• Number• Parent• Protocol• UserWksSecure

app.his.PrintService

• Account• ActivationRetryInterval• ActivationRetryLimit


• AlwaysDoNL• CanBePaused• CanBeStopped• DelayPrintStart• Description• DesktopInteract• DisplayName• DoAllFF• ErrorControl• ExitCode• FlushFinalFF• IgnoreCharsUnder3F• Name• NoEventLogOnSkippingTransparentSection• NoSpaceAfterFF• OperatingState• Parent• PathName• Server• ServiceName• ServiceSpecificCode• ServiceType• SoftwareVersion• StartMode• Started• UseFixedTabs• UseProportionalFontChange

app.his.SNAService

• ControlPoint• HISConnections• Name• NetworkName• Parent• Server


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


Troubleshooting the sensorThis topic describes common problems that occur with the HIS sensor and presents solutions for thoseproblems.

WMI service fails on a target during discoveryProblem

The Windows Management Instrumentation (WMI) service fails on a target system during discovery.Solution

Ensure that all WMI-related fixes, including fix KB933061, are applied on the target system. If theproblem persists, run the WMI diagnostic tools from Microsoft.

IBM Cluster Systems Management sensorThe IBM Cluster Systems Management sensor discovers IBM Cluster Systems Management (CSM) HighPerformance Computing (HPC) clusters.

Sensor name that is used in the GUI and logsCSMServerSensor and CSMNodeSensor

PrerequisitesGenericComputerSystemSensor, along with prerequisite sensors, must be enabled in the discovery profileused for discovering the CSM cluster.


• sys.hpc.cm.ConfigurationManagementCluster• sys.hpc.cm.ConfigurationManagementNode• sys.hpc.cm.ConfigurationMangementNodeGroup• sys.hpc.cm.ConfigurationManagementClusterConfigFile• sys.hpc.CSMNode


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

To configure the CSMServerSensor, complete the following steps:

1. Create a discovery profile and select agent configuration of type CSMServerAgentConfiguration.2. Set the following required attributes:

masterServerNamesThe IP addresses or host names of CSM master nodes. This property must be set to start the CSMserver 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.


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

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

CFMDiscoveryModeThe depth of file capture of the files and scripts in the CSM configuration directories. The validvalues are as follows:

• 0: No file information is captured.• 1: Only the file name and file information are captured.• 2: All file information and content is captured.

The default value is 1.

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

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

preRebootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/installprereboot/directory.The default value is "*".

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

postRebootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/installpostreboot/directory.The default value is "*".

osUpgradePreRebootScriptsLocationThe location of the scripts that are run after the OS is upgraded, but before reboot. The defaultvalue is /csminstall/csm/scripts/osupgradeprerboot/.

osUpgradePreRebootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/osupgradeprereboot/directory.The default value is "*".

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

osUpgradePostRebootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/osupgradepostreboot/ directory.The default value is "*".

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

disklessBootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/disklessboot/directory.The default value is "*".


disklessPreBuildScriptsLocationThe location of the pre-build scripts that are run for diskless nodes.The default value is /csminstall/csm/scripts/disklessprebuild/.

disklessPreBuildScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/disklessprebuild/directory.The default value is "*".

dataScriptsLocationThe location of any additional scripts or data files referenced by the scripts.The default value is /csminstall/csm/scripts/data/.

dataScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/data/ directory.The default value is "*".

updateScriptsLocationThe location of the scripts that are run after any CSM updates have completed.The default value is /csminstall/csm/scripts/update/.

updateScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/update/ directory.The default value is "*".

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

doPingNodesSpecifies whether ping sensors are run against discovered CSM nodes.

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


CSMServerSensor uses CSM Server access entry. If this access entry is not available, the sensor usesComputerSystem access entry to access the CSM server.

CSMNodeSensor uses ComputerSystem access entry to access CSM nodes.

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

Sensor name that is used in the GUI and logsHACMPSensor

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

Security issuesPrivileges to execute the following commands on the discovered systems are required: lssrc, clstat,cltopinfo, clRGinfo, cllsserv, cllsif, cllsfs, clshowres, cllsgrp,get_local_nodename, cllssite.


LimitationsThe following limitations apply:

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

the sensor runs the odmget command. However, the scope of data that is discovered by the odmgetcommand is limited because it does not include the state and substate attributes of the HACMP clusterobject.

Model objects with associated attributesThe IBM HACMP sensor creates model objects with associated attributes. The attributes indicate the typeof information that the sensor collects about configuration items in the IBM HACMP environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.HACMPAppResource

• AppServer• LocalAppResources• Name• Parent

HACMPCluster

• ClusterID• ComputerSystems• ConnAuthMode• HeartbeatNetworks• MessageAuthMode• MessageEncryption• Nodes• ResourceGroups• State• Substate• UsePersistentLabel

HACMPClusterHeartbeatNetwork

• Name• Netmask• NetworkElements• Parent• PrefixLength• Type

HACMPClusterHeartbeatNetworkElement

• L2Interface• Name• NetworkAddress• Parent


• StorageVolume• Type

HACMPClusterManager

• CurrentState• HacmpNode

HACMPLocalAppResource

• Node• Parent• StartScript• StopScript

HACMPLocalResourceGroup

• LocalState• Node• Parent

HACMPNode

• ClusterManager• LocalAppResources• LocalResourceGroups• Name• NetworkElements• Parent• SiteInfo• State• System

HACMPResourceGroup

• AppResources• FallbackPolicy• FalloverPolicy• FileSystems• GlobalState• LocalResourceGroups• Nodes• Parent• PrimaryNode• ServiceIpLabels• SitePolicy• StartupPolicy• StorageVolumes

ServiceIPLabel

• IpAddress• Name• Parent


SiteInfo

• Name


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

To configure the access list, complete the following steps:

1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM must use for authentication to

the target computer system.

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

The sensor uses the following entry in the collation.properties file:com.collation.platform.os.UnixOs.forcedServerList=clstrmgr

You must add the attribute clstrmgr to this entry to ensure that the sensor starts. For example,

com.collation.platform.os.UnixOs.forcedServerList=vxconfigd;clstrmgr

Troubleshooting the sensorThis topic describes common problems that occur with the IBM HACMP sensor and presents solutions forthose problems.

HACMP cluster is duplicatedProblem

A duplicate HACMP cluster might be created in the following scenario:

1. A HACMP cluster is discovered.2. The HACMP cluster name is changed in the cluster configuration.3. The HACMP cluster is discovered again.

SolutionTo resolve a situation where a HACMP cluster has been duplicated, using the Data ManagementPortal, delete the copy of the cluster that has the old cluster name.

Incorrect HACMP version returnedProblem

When discovering a HACMP cluster with the IBM HACMP sensor, the product version of the HACMPcluster might be incorrectly discovered as "0".

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

To manually check the cluster version, run the following command on one of the HACMP clusternodes:

ssrc -ls clstrmgrES

In the command output, check the version of the HACMP cluster, for example

local node vrmf is 0


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

Clstat and cldump commands do not work on nodes directly installed on AIX 6.1Problem

When a HACMP cluster is installed on nodes that are directly installed on AIX 6.1, the clstat andcldump commands do not work.

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

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

Sensor name that is used in the GUI and logsDominoDomainSensor, DominoServerDetailSensor, and DominoInitialSensor

PrerequisitesOn the Lotus Domino system, a user account must be configured with the correct access to the resourcesbeing discovered. Ensure that the following requirements are met:

• The Internet Inter-ORB Protocol (IIOP) server must be running on at least one Domino server for eachDomino domain.

• Add the IP address or the fully qualified domain name (FQDN) of the IIOP servers to the$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.5.0/plugin.xml file.You can append the port number of the Domino IIOP server to the server name. Adding the port numberis 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>

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

about Domino clusters.• 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 theresources being discovered, for example, files and databases.

• 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.5.0/plugin.xml fileto true. Then, you must copy the TrustedCerts.class file to the $COLLATION_HOME/etc/


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

domino_trusted directory on the TADDM server. The TrustedCerts.class file is located in thedomino data folder/domino/java folder.

• Issue the show task command in the Domino console to determine if the DIIOP task is running.• If the DIIOP task is not running, issue the load diiop command using the Domino console to load the

DIIOP task.• 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.


• app.lotus.AgentManager• app.lotus.AdminProcess• app.lotus.DirectoryAssistance• app.lotus.DirectoryCataloger• app.lotus.DomainCatalog• app.lotus.DominoCluster• app.lotus.DominoConnection• app.lotus.DominoDatabase• app.lotus.DominoDomain• app.lotus.DominoNamingContext• app.lotus.DominoReplicas• app.lotus.DominoSecurity• app.lotus.DominoServer• app.lotus.DominoTransactionLogging• app.lotus.HTTPFilterSpecialtyServer• app.lotus.IIOPConfig• app.lotus.IMAPConfig• app.lotus.InternetClusterManager• app.lotus.LDAPConfig• app.lotus.OtherDatabase• app.lotus.POPConfig• app.lotus.RemoteDebugManager• app.lotus.SMTPConfig• app.lotus.SpecialityServer• app.lotus.WebConfig• app.lotus.WebRetriever

Asynchronous and script-based discovery supportThe IBM Lotus Domino server sensor supports asynchronous and script-based discovery. Also, in anonscript-based discovery, the Lotus Domino server sensor is not supported on the Solaris operatingsystem, but in an asynchronous or a script-based discovery, the sensor is supported on the Solarisoperating system.





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

LimitationsMost function that is provided by the Lotus Domino server sensor during a nonscript-based discovery isnot supported in an asynchronous or script-based discovery.

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


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


1. From the Discovery Management Console, create a discovery scope set that contains the IP address ofthe Lotus Domino server.

2. To create an access list, click the Access List icon.3. In the Access List window, click Add.4. In the Component Type field of the Access Details window, click Messaging servers.5. In the Vendor field of the Access Details window, click Domino.6. Type the credentials to access the target Lotus Domino server.

You must also have an access list entry and credentials for Windows systems. The Session sensor createsa session between the TADDM server and the target computer systems before the IBM® Lotus® Domino®

server sensor discovery run.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM Lotus Domino server sensor and presentssolutions for those problems.

The sensor does not startProblem

If the Domino Internet Inter-ORB Protocol (DIIOP) is not running or the plugin.xml file is notcorrectly configured, the sensor does not start or it fails.

Solution

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

• Using the Domino Console, run the following commands:

– load diiop– show tasks


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

For AIX operating systems, if the notes.ini file is not found in the processing environment thesensor does not start.

SolutionThe user ID carrying out the discovery does not have access to the process environment due tosecurity 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.

IBM Tivoli Monitoring Scope sensorUsing the credentials for the Tivoli Enterprise Portal Server rather than the credentials for each computerthat the portal server monitors, the IBM Tivoli Monitoring Scope sensor discovers configuration items inthe IBM Tivoli Monitoring environment.

The IBM Tivoli Monitoring Scope sensor provides the following discovery capability:

• Provides basic discovery of Tivoli Monitoring endpoints, similar to a standard TADDM Level 1 discovery.The sensor discovers IP addresses, MAC addresses, and the operating system type for each computersystem that is managed by Tivoli Monitoring.

• Creates special scope sets for all Tivoli Monitoring endpoints that it discovers so that all future TADDMLevel 2 (and some Level 3) discoveries can be run without needing access credentials for the TivoliMonitoring endpoints.

Also see the TADDM Administrator's Guide for information about configuring for discovery using IBM TivoliMonitoring.

Sensor name that is used in the GUI and logsITMScopeSensor and ITMScopeSensor-x.xx.xxx.xxx.log, where x.xx.xxx.xxx represents the IP address ofthe discovered system.

The IBM Tivoli Monitoring Scope sensor also logs information to local-anchor.hostname.ITMScopeSensor.log, where hostname represents the host name of the TADDMserver.

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

LimitationsDiscovery using the Tivoli Monitoring Scope sensor causes the following performance impacts in the TivoliMonitoring environment:

• An increase in CPU usage on the Tivoli Enterprise Portal Server and the Tivoli Enterprise MonitoringServer

• An increase in network utilization• 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 theperformance 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).


Model objects with associated attributesThe IBM Tivoli Monitoring Scope sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about configuration items in the IBM TivoliMonitoring environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.net.IpInterface

• IpAddress

Multiple computer systems, with the following model objects:

sys.aix.AixUnitaryComputerSystemsys.hpux.HpUxUnitaryComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.Solarissys.sun.SunSPARCUnitaryComputerSystemsys.UnitaryComputerSystemsys.windows.WindowsComputerSystemsys.zOS.ZSeriesComputerSystem

The following attributes are associated with these model objects:

• Fqdn• Ipinterface• Name• OSInstalled• OSRunning• Signature• Type

Multiple operating systems, with the following model objects:

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


• Name• ManagedSystemName• OSVersion


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

Copying necessary files from the Tivoli Enterprise Portal Server to the TADDM serverYou 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 thesensor for the first time. You do not complete this procedure if you already copied the files from the TivoliEnterprise Portal Server to the TADDM server in version 7.2.1.x and you upgraded to version 7.2.2 or later.

1. On the TADDM server, verify that the $COLLATION_HOME/lib/itm directory exists.2. Copy the following files from the Tivoli Enterprise Portal Server into the $COLLATION_HOME/lib/itm

directory on the TADDM server:

• browser.jar• 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. Note: Skip this step if you're integrating with ITM 6.3 or later.

Copy the cfwk.zip from the Tivoli Enterprise Portal Server into the $COLLATION_HOME/lib/itmdirectory on the TADDM server.

On Windows systems, copy the file from the ITM_INSTALLATION_DIR\GSK7\classes directory.

On Linux and UNIX systems, copy the file from the ITM_INSTALLATION_DIR/ARCH/gs/classesdirectory.

4. On Linux and UNIX systems, use the following command to set the user and group of the previouslycopied files to the user and group that is used to run the TADDM server:

chown -R taddmuser:taddmuser $COLLATION_HOME/lib/itm

5. Restart the TADDM server.

Distributing the discovery target support bundleDuring the discovery process, TADDM must copy binary file data between itself and the discovery targetusing IBM Tivoli Monitoring as an intermediary. For Windows discovery targets, the discovery targetsupport enables binary files to be copied from TADDM to the discovery target as part of the discoveryprocess. The discovery target support bundle also provides part of the Windows gateway on the target sothat the gateway is available during discovery. This method prevents you from having to deploy a separateWindows discovery gateway within your Tivoli Monitoring environment. The discovery target supportbundle is not required on Linux, AIX, Solaris, and HP-UX operating systems.

Before the first discovery from TADDM, the discovery target support bundle must be deployed onto eachTivoli Monitoring Windows operating system endpoint. The bundle has a small footprint and is designed tobe non-intrusive and used only during a TADDM discovery. If you are performing a Level 1 discovery, thistask is not required.

You must distribute the support bundle to the Windows discovery targets through the Tivoli EnterpriseMonitoring Server depot. The support bundle must also be loaded into any remote Tivoli EnterpriseMonitoring Server depots that exist in your Tivoli Monitoring environment.


In addition to deploying the discovery target support bundle, you must ensure that each Tivoli Monitoringendpoint is configured for discovery. For example, each UNIX-based endpoint must have the LiSt OpenFiles (lsof) program installed. For more information, see the TADDM Administrator's Guide.

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 orlater, 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 TivoliEnterprise Monitoring Server. For example, the C:\TEMP directory on Windows and /tmp on Linux orUNIX 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\072200000

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

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

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

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

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

On Linux or UNIX operating system:

[root@localhost bin]# /opt/IBM/ITM/bin/tacmd login -s localhost -u sysadmin -p "mypassword"

Validating user...

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

KUICAB023I: Are you sure you want to add the following bundles to the /opt/IBM/ITM/tables/TEMS/depot depot? Type : ComponentProduct Code : d7Deployable : trueVersion : 072200000Description : TADDM Discovery through ITM enablementHost Type : WINNTHost Version : WINNTPrerequisites:

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

KUICAB020I: Adding bundles to the /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 tacmdlistSystems -t NT command. For more information about the tacmd listSystems -t NTcommand, see tacmd CLI commands at: http://www-01.ibm.com/support/knowledgecenter/SSTFXA_6.2.2.2/com.ibm.itm.doc_6.2.2fp2/tacmd.htm.

4. To distribute the support bundle from the Tivoli Enterprise Monitoring Server to the discovery targets,log in to the Tivoli Enterprise Monitoring Server, and run the tacmd command, as shown in thefollowing sample:On Windows operating system:

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

On Linux or UNIX operating system:

[root@localhost bin]# /opt/IBM/ITM/bin/tacmd login -s localhost -u sysadmin -p "mypassword"

Validating user...

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

KUICAR010I: The agent type d7 is being deployed.

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

5. Check the status of deployment by entering the tacmd getDeployStatus command. For example:

C:\IBM\ITM\bin>tacmd getdeploystatus -g 121969167781300000018467

Transaction ID : 121969167781300000018467 Command : INSTALL Status : SUCCESS Retries : 0 TEMS Name : HUB_TEMS Target Hostname: Primary:OMPDEV2:NT Platform : WINNT Product : D7 Version : 072200000 Error Message : KDY0028I: Request completed successfully. Deployment request was processed successfully and is now completed.

Installing custom queries on the Tivoli Enterprise Portal ServerFor both Level 1 and Level 2 discovery through IBM Tivoli Monitoring, you must install custom queries onthe Tivoli Enterprise Portal Server to support the lookup of managed system MAC addresses and agentversions by the IBM Tivoli Monitoring Scope sensor.

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

These queries return the following information:

• Version number of the agent on each endpoint• MAC address of each Linux endpoint• Operating system name and version of each endpoint

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


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

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

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 andextracted. The install_zkd7.sql and uninstall_zkd7.sql files are then located inthe /tmp/teps directory.

2. Install the custom queries:

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

3. Stop the Tivoli Enterprise Portal Server:

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

4. Start the Tivoli Enterprise Portal Server:

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

Installing on Windows operating system:


In these instructions, the TEPS_Query.zip file is copied to the c:\TEMP\TEPS directory andextracted. The install_zkd7.sql and uninstall_zkd7.sql files are then located in thec:\TEMP\TEPS directory.

2. Change to the directory where the Tivoli Enterprise Portal Server is installed:

cd c:\IBM\ITM\CNPS

3. Install the custom queries:

.\kfwsqlclient.exe /d KFW_DSN /f c:\TEMP\TEPS\install_zkd7.sql

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

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

To create the discovery profile, complete the following steps:

1. From the Discovery Management Console, click the Discovery Profiles icon.2. In the Discovery Profiles window, click New.3. In the Create New Profile window, type the profile name and description. In the Clone existing

profile field, click Level 1 Discovery or Level 2 Discovery, and click OK.4. In the list of sensors, click ITMScopeSensor, and click New.5. In the Create Configuration window, type the name and description for your configuration of the

ITMScopeSensor, and select the Enable 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, andtype 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 Valuefield in the row, and type false.


The default value for useDefaultPortList is true. If a port list is provided and useDefaultPortList isset 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 adiscovery, 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 anythingin the field, or type false.

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

Discovering endpoints behind firewallsThe IBM Tivoli Monitoring Scope sensor supports the Tivoli Monitoring endpoints that are behind afirewall.

1. Run a Level 1 discovery of your ITM environment to create the itmserver.properties file.2. Include the sensor in your profile and set the startSessionOnly parameter to true in the configuration

options.

The sensor checks whether the IP address from the original scope is managed by ITM, and runs a sessionsensor. 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. Ifenabled, the sensor does not start any other operations.

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


1. From the Discovery Management Console, create a discovery scope set that contains your TivoliEnterprise Portal Server, or use an existing scope that contains your Tivoli Enterprise Portal Server.

2. To create an access list, click the Access List icon.3. In the Access List window, click Add.4. In the Component Type field of the Access Details window, click Integration.5. In the Vendor field of the Access Details window, click IBM Tivoli Monitoring.6. Type the credentials for the Tivoli Enterprise Portal Server. Use the credentials that are required to log

in to the Tivoli Enterprise Portal Server rather than the credentials for the computer on which the TivoliEnterprise Portal Server resides.

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

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

To delete an access list entry, complete the following steps:

1. From the Discovery Management Console, delete any discovery scope sets that contain your TivoliEnterprise Portal Server.

2. To delete an access list, click the Access List icon.3. In the Access List window, select each IBM Tivoli Monitoring access list, and click Delete for each one.

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

To delete a discovery profile, complete the following steps:


1. From the Discovery Management Console, click the Discovery Profiles icon.2. In the Discovery Profiles window, select each of the discovery profiles created for the IBM Tivoli

Monitoring, and click Delete.

Uninstalling custom queries on the Tivoli Enterprise Portal ServerTo uninstall the IBM Tivoli Monitoring Scope sensor configuration, you must uninstall custom queries onthe Tivoli Enterprise Portal Server.

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

To uninstall the custom queries on the Tivoli Enterprise Portal Server, complete the following steps:Uninstall on Linux operating system:


In these instructions, the TEPS_Query.zip file is copied to the /tmp/teps directory andextracted. The uninstall_zkd7.sql file is then located in the /tmp/teps directory.

2. Run the uninstall query:

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

3. Stop the Tivoli Enterprise Portal Server:

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

4. Start the Tivoli Enterprise Portal Server:

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

Uninstall on Windows operating system:


In these instructions, the TEPS_Query.zip file is copied to the c:\TEMP\TEPS directory andextracted. The uninstall_zkd7.sql file is then located in the c:\TEMP\TEPS directory.

2. Change to the directory where the Tivoli Enterprise Portal Server is installed:

cd c:\IBM\ITM\CNPS

3. Run the uninstall query (supports all platforms):

.\kfwsqlclient.exe /d KFW_DSN /f c:\TEMP\TEPS\uninstall_zkd7.sql

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

Removing the discovery target support bundleTo uninstall the IBM Tivoli Monitoring Scope sensor configuration, you must remove the target supportbundle on the Tivoli Enterprise Monitoring Server depots.

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

To remove the support bundle from the agent depot, follow these steps:

1. Extract the KD7.zip file into a directory on the Tivoli Enterprise Monitoring Server (for example, theC:\TEMP directory).

2. To remove the support bundle from the discovery targets, log in to the Tivoli Enterprise MonitoringServer. Run the tacmd command, as shown in the following sample. Provide the product code (D7)


using the -t option, and the managed system where the bundles are to be removed using the -noption.

tacmd removesystem -t D7 -n Primary:Sirius:NT

3. To remove the support bundle from the Tivoli Enterprise Monitoring Server depot, run the tacmdcommand, as shown in the following sample. Provide the path to the directory where the installablebundles are located, using the -i option.

tacmd removeBundles -i C:\TEMP\KD7\072200000

Deleting the Tivoli Enterprise Portal Server files from the TADDM serverTo uninstall the IBM Tivoli Monitoring Scope sensor configuration, you must delete the files that werecopied 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/lib/itm directory.2. Restart the TADDM server.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM Tivoli Monitoring Scope sensor andpresents solutions for those problems.

Computer systems that are outside of the defined scope are createdProblem

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 theTivoli Enterprise Portal Server. This creation occurs even if an endpoint is outside of the initialdiscovery scope that included the portal server.

Updates made to the generated Tivoli Monitoring scope using the DiscoveryManagement Console are overwrittenProblem

Updates that have been made to the generated Tivoli Monitoring scope in the previous discovery usingthe Discovery Management Console are overwritten.

SolutionDuring a Level 1 discovery, a new scope is created based on the name of the Tivoli Enterprise PortalServer. This scope is overwritten the next time that the portal server is discovered during a Level 1 orLevel 2 discovery.

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

In a large Tivoli Monitoring environment, the sensor fails with a timeout errorProblem

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 ofmilliseconds allowed for the sensor to run (for example, 60000 is 1 minute):

com.collation.discover.agent.ITMScopeSensor.timeout=value


The sensor fails with a timeout error when slow network links or many router hopsexist between the target systems and the Tivoli Enterprise Portal Server or TADDMProblem

The Tivoli Monitoring Scope sensor fails with a timeout error. Slow network links or many router hopsexist between the target systems and the Tivoli Enterprise Portal Server or TADDM. The environmentincludes Windows, Linux, and UNIX systems.

SolutionThis problem is caused by TCP buffer settings. Because the buffer sizes are sometimes too small, poorperformance occurs with the TADDM sensors and the Tivoli Enterprise Portal Server.

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


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 afterdeploying the discovery target support bundleProblem

One or more of the following messages result from running the tacmd getDeployStatus commandafter deploying the discovery target support bundle:

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

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

• Error Message: KDY1024E: The agent failed to respond to thecommand C:\itmagent\installITM\Batch\kincli -startagent -akd7 did not start or stop agent. The command returned a failure return code.


SolutionThese messages do not indicate actual errors, because the discovery target support bundle is notintended to respond to the agent start or stop command. The Tivoli Monitoring cinfo commandalso does not list the support bundle, because the support bundle is an addition to the existing OSagent.

Verify that the discovery target support bundle is correctly installed on the discovery target. From theTivoli Monitoring directory on the target computer, run the directory command as shown in thefollowing example:

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 06:38 PM <DIR> .09/24/2010 06:38 PM <DIR> ..09/24/2010 06:38 PM 6,656 Base64.exe09/24/2010 06:38 PM 1,960 KD7WINNT.dsc09/24/2010 06:38 PM 1,363 post.bat09/24/2010 06:38 PM 4,280 pre.bat09/24/2010 06:38 PM 249,856 TaddmTool.exe09/24/2010 06:38 PM 474,624 TaddmTool.pdb09/24/2010 06:38 PM 569,344 TaddmWmi.dll09/24/2010 06:38 PM 106,496 TaddmWmi.exe09/24/2010 06:38 PM 1,424 TaddmWmi.mof09/24/2010 06:38 PM 2,968,576 TaddmWmi.pdb 10 File(s) 4,384,579 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 EnterprisePortal Server is runningProblem

When you run the IBM Tivoli Monitoring Scope sensor for a Level 2 discovery on Windows targetsystems, multiple command windows open on the computer where the Tivoli Enterprise Portal Serveris running.

SolutionThe IBM Tivoli Monitoring Windows OS Agent is probably configured to run as a system service, andthe option Allow Service to Interact with Desktop is enabled. Complete the following steps tocorrect this problem:

1. Right-click the agent in the Manage Tivoli Monitoring Services program.2. Click Change Startup.3. In the "Log on As" pane of the window that opens, clear the Allow Service to Interact with

Desktop check box.4. Click OK.5. Again, right-click the agent in the Manage Tivoli Monitoring Services program.6. Click Recycle.

Temporary files are in the log directory of the target systemProblem

During a Level 2 discovery through IBM Tivoli Monitoring, some commands fail on endpoints, whichcauses multiple KD7* files or session_script*.bat files to be in the log directory of the targetsystem. These files might also be present for other reasons, such as a discovery that ended


prematurely or a problem with the Tivoli Monitoring agent connection to the Tivoli EnterpriseMonitoring Server.

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

Trailing white spaces exist in the output from discovery targetsProblem

If you create custom server templates that run under the IBM Tivoli Monitoring Scope sensor, trailingwhite spaces (such as newline characters or carriage returns) might exist in the output from discoverytargets.

SolutionTo ensure that custom server templates provide the same output when used with the Tivoli MonitoringScope sensor, remove white spaces in the server-side logic of the custom server template.

After upgrading IBM Tivoli Monitoring, errors occur during discoveryProblem

After upgrading IBM Tivoli Monitoring, errors might occur during discovery for the following reasons:

• A result of updates to the Tivoli Monitoring libraries or agent tables• A result of updates to the TADDM discovery logic

SolutionIf the errors result from updates to the Tivoli Monitoring libraries or agent tables, redo the followingtasks:

• “Copying necessary files from the Tivoli Enterprise Portal Server to the TADDM server” on page 50• “Installing custom queries on the Tivoli Enterprise Portal Server” on page 52

If the errors result from updates to the TADDM discovery logic, redo the following tasks:

• “Copying necessary files from the Tivoli Enterprise Portal Server to the TADDM server” on page 50• “Distributing the discovery target support bundle” on page 50• “Installing custom queries on the Tivoli Enterprise Portal Server” on page 52• “Configuring the discovery profile” on page 53• “Configuring the access list” on page 54

If none of the above solutions works, make sure that thecom.ibm.cdb.discover.ITM.https.strictChecking property in thecollation.properties file is set to false. By default, this property is not added to thecollation.properties file, which means that its default value is false. This property is used onlywith the SSL session. If you set it to true, the connection host name must match the certificate hostname. Otherwise, the discovery fails.

Errors occur during discovery of a Tivoli Monitoring 6.2.2 environmentProblem

During the discovery of a Tivoli Monitoring Version 6.2.2 environment, the Tivoli Enterprise MonitoringServer might shut down unexpectedly, resulting in the following TADDM error messages:

• CTJTD0203E The Computer System agent cannot retrieve the host and IP information for the following computer system

• CTJTD3000E Starting - An error occurs and the sensor timed out


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

Tivoli Monitoring scope does not include all endpoints defined on the TivoliEnterprise Portal ServerProblem

The Tivoli Monitoring scope created during a discovery does not include all the endpoints that aredefined on the Tivoli Enterprise Portal Server.

SolutionInactive endpoints and endpoints for which MAC addresses cannot be resolved are not included in acreated scope set.

Targets are discovered by IBM Tivoli Monitoring session but not by SSH or WMIduring a Level 2 discoveryProblem

When an endpoint is discovered by the IBM Tivoli Monitoring Scope sensor, future Level 2 discoveriesuse Tivoli Monitoring for discovery by default. A direct connection (SSH or WMI) is not used. Thismethod is used even if the IBM Tivoli Monitoring Scope sensor is not included in the discovery profile.

SolutionTo discover the endpoint through SSH or WMI, define the following property in thecollation.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 howTADDM discovers Tivoli Monitoring endpoints.

Too many active report queries on the Tivoli Enterprise Portal ServerProblem

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.

SolutionIncrease the maximum number of pending requests. Edit the configuration settings on the TivoliEnterprise Portal Server, on Windows operating systems edit the KFWENV file, and on Linux or UNIXoperating 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 theTivoli Enterprise Portal Server from a single client. The KFW_REPORT_REQUEST_LIMIT_MAX specifiesa 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 (inseconds).


IBM WebSphere sensorThe IBM WebSphere sensor discovers IBM WebSphere Application Server node information, cellinformation, and version information.

TADDM captures all the configuration files and configuration information from the WebSphere NetworkDeployment Manager system. If changes are made to the files on the Deployment Manager System, theymight not be the same on the actual distributed node system. This difference can be caused by the timetaken to update the file changes on the distributed node system. Therefore, a configuration change that isflagged on a distributed node might not reflect what is actually on the distributed node.

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

Sensor name that is used in the GUI and logsWebSphereCellSensor, WebSphereJDBCDriverSensor, WebSphereNodeSensor, WebSphereVersionSensor,and WebSphereScriptSensor.

PrerequisitesFor IBM WebSphere JDBC driver discoveries, ensure that the following prerequisites are met:

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

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


• For discovery using IBM Tivoli Monitoring, TADDM supports only script-based discovery for theWebSphere sensor.

• JDBC connections that use native DB aliases configured in native DB clients are not supported.• 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 discoveryscope, the local-anchor log shows the following messages:

CTJTD1121W verifyStandaloneServer() determined cell to be distributed (DISTRIBUTED), terminating discoveryCTJTD1116W Terminating discovery of managed server/nodeagent <SERVER NAME> - discovery will be handled at cell level

• The JVM runtime information that is the Java version and publisher name is discovered for each serverthat is running. The discovery of the runtime information is dependent on cell and node agentsynchronization. Synchronization must be enabled for every node within a cell. The synchronizationinterval determines how up to date the discovery is. The most current information is gathered from thecell after the JVM information is propagated from the node agent.

• The JDBC driver version for JDBC providers is not discovered for WebSphere Application Serversrunning on z/OS®

• Due to a known problem with the WebSphere Application Server, interim fix information is not collectedfor some versions of the WebSphere Application Server (such as WebSphere Application Server 8.0.0.0and 8.0.0.1).

• When you discover JDBC drivers from WebSphere Application Server, the data is not populated. Ithappens because JDBC data sources do not use IP addresses but host names (FQDNs), while TADDMrelies on DNS. When the dependencies between WebSphere Application Server and database serversare created, the /etc/hosts file is not read.



• app.AppConfig• app.AppServer• app.ConfigFile• app.SoftwareContainer• app.j2ee.J2EEComponent• app.j2ee.J2EEDeployedObject• app.j2ee.J2EEModule• app.j2ee.J2EEResource• app.j2ee.JDBCDriver• app.j2ee.websphere.WebSphereAuthMappingModule• app.j2ee.websphere.WebSphereCell• 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• app.j2ee.websphere.WebSphereJMSProvider• app.j2ee.websphere.WebSphereJMSQueue• app.j2ee.websphere.WebSphereJMSTopic• 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• app.j2ee.websphere.WebSphereSSLSettings• app.j2ee.websphere.WebSphereUserRegistry• app.j2ee.websphere.WebSphereVariable• app.j2ee.websphere.WebSphereVirtualHost• app.j2ee.websphere.WebSphereWebModule

• app.j2ee.websphere.WebSphereGroup

• app.j2ee.websphere.WebSphereRole

• app.j2ee.websphere.WebSphereUser• app.JVM

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


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

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



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

Running discoveriesWhen discovering a distributed WebSphere cell, most of its configuration is collected from its masterrepository, which is stored in the DMGR's node. However, other hosts that belong to the cell must also bediscovered to create relationships between WebSphere servers and computer systems that they run on.

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

LimitationsSome function that is provided by the WebSphere sensor during a nonscript-based discovery is notsupported in an asynchronous or script-based discovery.


The following model objects are not supported:

• app.j2ee.JDBCDriver• app.j2ee.websphere.WebSphereConnector


• app.j2ee.websphere.WebSphereEFixInfo• app.j2ee.websphere.WebSphereLibraryRef• app.j2ee.websphere.WebSphereServlet• app.j2ee.websphere.WebSphereSessionTuningParams• app.j2ee.websphere.WebSphereSharedLibrary• app.JVM

Only the following configuration files are stored in the TADDM database:

• From <PROFILE_HOME>/config/cells/<CELL_NAME>/:

– cell.xml– resources.xml– virtualhosts.xml– variables.xml– security.xml

– fileRegistry.xml

– admin-authz.xml

– audit-authz.xml• From <PROFILE_HOME>/config/cells/<CELL_NAME>/nodes/<NODE_NAME>/:

– node.xml– variables.xml– resources.xml– serverindex.xml– spi.policy– app.policy– library.policy

• From <PROFILE_HOME>/config/cells/<CELL_NAME>/nodes/<NODE_NAME>/servers/<SERVER_NAME>/:

– server.xml– variables.xml– resources.xml

Note: The following limitation applies only to 7.3.0 version of TADDM, it does not apply to version 7.3.0.1,and later.

The app.ProcessPool objects are discovered only for the servers that run on a DMGR's host.

Configuring the sensorBefore running a discovery, depending on the type environment you might have to configure the IBMWebSphere sensor.

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

To enable the WebSphere JDBC driver sensor, complete the following steps:

1. Create a Level 3 discovery profile.2. For the WebSphere cell sensor, enable the deepDiscoveryLevel configuration item.3. Enable the WebSphere JDBC driver sensor in the new discovery profile.


4. Set the appropriate configuration options for the WebSphere JDBC driver sensor. The followingconfiguration options are available:

• You can configure for a prefix to be added to every command run by the WebSphere JDBC driversensor on the target host. You can configure a different prefix for UNIX and Windows systems. Bydefault, a prefix is not defined.

• You can configure for the sensor to remove the OracleUtility file after discovery completes. TheOracleUtility file is an auxiliary file used by TADDM on target hosts to discover JDBC driverinformation for Oracle databases. By default, the OracleUtility file is not removed.

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

Note: Changing the discovery level does not apply to the script-based or asynchronous discovery mode,because WebSphereScriptSensor has no configuration properties.

To change the default the discovery level for this sensor, complete the following steps:

1. In the Discovery Profiles window, click New.2. In the Create New Profile window, type the profile name, description, and click OK.3. In the list of sensors, click the WebSphereCellSensor, and click New.4. In the Create Configuration window, type the name and description for your configuration of the

WebSphereCellSensor, and select the Enable Configuration check box.5. In the Configuration section of the Create Configuration window, to change the discovery level value,

select one of the following choices:

• To enable medium discovery, double-click the value for mediumDiscoveryLevel and change fromfalse to true

• To enable deep discovery, double-click the value for deepDiscoveryLevel and change from false totrue

If deepDiscoveryLevel is set to true, it runs a deep discovery regardless if shallow and mediumdiscoveries are set to true or false.

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

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

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

10. Choose this discovery profile when running a discovery.

For more information about Discovery Profiles, see the Using discovery profiles topic in the TADDM User'sGuide.

Sensor propertiesshallowDiscoveryLevel, mediumDiscoveryLevel, deepDiscoveryLevel

The WebSphere sensor has three discovery levels, shallow, medium, and deep. By default the shallowdiscovery level is enabled. To modify the discovery level value, select one of the following choices:

• To enable medium discovery, double-click the value of mediumDiscoveryLevel and change false totrue.

• To enable deep discovery, double-click the value of deepDiscoveryLevel and change from false totrue.

If the deepDiscoveryLevel is set to true, it runs a deep discovery regardless of whether shallow andmedium discoveries are set to true or false.


• The following list contains the information that is captured at each discovery level.

– Shallow discovery discovers the following components:

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

– Medium discovery discovers the following components:

- Clusters- Configuration files- Connections- Deployed connector modules- Deployed EJB modules- Deployed Java EE applications- Deployed web modules- Efixes- EJB containers- End points- JVM settings- Ports- Process definition- Process monitoring policy- Process pools- Security, SSL settings, and user registries- Virtual hosts- Web containers

– Deep discovery discovers the following components:

- Cell, node, server, cluster JDBC providers, JDBC data sources, and JDBC dependencies- Custom properties- Deployment descriptors for Java EE applications and modules- JMS providers and JMS destinations- Shared libraries- Variables- Web services- Dynamic cache service settings for servers and dynamic clusters

traceSpecification

Sets the trace specification string for enabling trace logging of the WebSphere client code called bythe TADDM WebSphere sensor. sample value - Admin=all=enabled

Caution: The preceding value generates verbose trace logging. Not setting any value prevents tracelogging.


traceOutputFile

Allows you to specify the full path name of the output file to be used for logging trace output. Leavethis 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 troubleshootingpurposes. FFDC logs capture the failure path through the WebSphere client code in a subdirectorynamed 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 usermust have write access.

Configuring the access listThis topic describes the access details that you require depending on type of configuration that you areusing.

Note: Configuring the access list does not apply to the script-based or asynchronous discovery mode,because WebSphereScriptSensor requires only an OS-level user in the TADDM access list.


1. If security is disabled, no user accounts are needed.2. If security is enabled, specify the following details:

a. For the component type, specify Application Server.b. For the vendor, specify WebSphere.c. Specify the username and password of WebSphere Application Server.d. In SSL Settings, upload two certificates, trust, and keystores, with their passphrases. The default

passphrase is WebAS.3. For the WebSphere JDBC driver sensor, complete the following steps:

a. For the component type, specify Application Server.b. For the vendor, specify WebSphere SSH.c. Specify the username and password of a system account with appropriate privileges. If the

WebSphere SSH access list is not specified, the WebSphere JDBC driver sensor will try to log in withComputerSystem credentials.

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

5. Disabling security does not mean that you are not using SSL. Check whether you are prompted for apassword when you connect to the WebSphere Application Server Admin Console.

• If you need only a user name to log on to the Admin Console, security is disabled.• If you need a user name and password to log on to the Admin Console, security is enabled.• If the connection to the Admin Console is through https (look at the URL in your web browser), you

need the certificates.

Access to Configuration Files• In general, the WebSphere Application Server sensor captures the following configuration files:

– WebSphere Application Server cell– WebSphere Application Server node– WebSphere Application Server server


This information is made available for the change history over time. It is also made visible in theDiscovery Management Console (Configuration files tab of the Details panel) for each of the precedingconfiguration items.

• When the sensor starts, it also uses the following two files to make key decisions about the discovery ofWebSphere Application Server:

– $WAS_ROOT/config/cells/cell_name/cell.xml

This helps to determine if the system is ND or stand-alone WebSphere Application Server. If readaccess to this file is not available, the sensor continues and uses JMX to determine whether it is anND 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 thisfile is not available, the sensor attempts to set up a JMX connection by cycling through all the listenports of the WebSphere Application Server server/dmgr being discovered. The ports are tried inascending order since this method results in quicker identification of the JMX port.

Certificate setupIf security is enabled when you discover WebSphere Application Server, you must set the SSL certificatesin the access list entries. TADDM supports PKCS12 and JKS certificate store types. The truststore andkeystore files must be present on the computer that runs the TADDM console, not on the TADDM server.

Note: Setting up certificates does not apply to the script-based or asynchronous discovery mode, becauseWebSphereScriptSensor requires only an OS-level user in the TADDM access list.

Truststore and keystore files are typically in the $PROFILE_HOME/etc directory on the system on whichWebSphere Application Server is installed. By default, the following files are certificate stores:

• PKCS12

– $PROFILE_HOME/etc/trust.p12– $PROFILE_HOME/etc/key.p12

• 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 bydownloading certificates with the WebSphere Application Server console.

TADDM requires a truststore with signer certificate only for connecting with DMGR, in the case ofWebSphere Application Server Network Deployment (ND), and server1, in the case of a stand-aloneserver.

Because of the restrictions of the JMX protocol, which is used to retrieve data from WebSphereDeployment Manager or from a stand-alone server, TADDM can handle only one truststore file for a singlediscovery. The certificates that are stored in the truststore file are loaded when the connection withWebSphere Application Server is established. Only those certificates can be used by TADDM during theentire discovery, so if certificates from several truststores are required, do not attach them separately intothe access list. You must export the original truststores to a single file, either manually or through acollectwascerts script that is bundled with TADDM. When all necessary entries for each WebSphereserver are in the TADDM access list, the first one must have the exported truststore and keystore filesattached. There is always one entry for each different login and password combination for the discoveredWebSphere servers.


Creating a single truststore with the collectwascerts scriptTADDM can use only one truststore file for a single discovery. If you want to use certificates from severaltruststores, you must export those truststores to a single file. You can use the collectwascerts scriptthat downloads the certificates to export them.

1. Edit the $COLLATION_HOME/bin/collectwascerts.config file.

Add a line for each WebSphere server from which you want to download the certificates. Fordistributed cells, you need only certificates from the deployment manager (DMGR) to run a successfuldiscovery. If you start a line with a number sign (#), it is treated as a comment and is not processed.

Each line must have the following format:

<Server IP/HOSTNAME/FQDN><SOAP port number><username><password>

156.24.24.11 8879 wasadmin waspassword

You can find the value of the SOAP port number in the Ports section of DMGR or server panel in theWAS administration console. The exact name is SOAP_CONNECTOR_ADDRESS.

2. Run $COLLATION_HOME/bin/collectwascerts.sh (or $COLLATION_HOME/bin/collectwascerts.bat) on your TADDM host, even if the collectwascerts.config file has noentries. The file might not have any entries because all the WAS servers can be reached from theanchor servers only.

All retrieved certificates are stored in $COLLATION_HOME/bin/collectedwascerts.jks. Thepassphrase is written by the tool to the standard output. You can also read it from thecom.collation.sslpassphrase property in $COLLATION_HOME/etc/collation.properties.

Complete the optional steps only if your WAS environments are not accessible directly from yourTADDM server.

3. Optional: Copy the collectedwascerts.jks file from the TADDM host to your first anchor.

Copy the file to the bin directory that contains the collectwascerts.config,collectwascerts.bat, and collectwascerts.sh files.

4. Optional: Run collectwascerts.sh (or collectwascerts.bat) on the anchor host.5. Optional: Copy collectedwascerts.jks from the anchor host to the next anchor.

Copy the file to the bin directory that contains the collectwascerts.config,collectwascerts.bat, and collectwascerts.sh files.

6. Optional: Run collectwascerts.sh (or collectwascerts.bat) on the next anchor host.7. Optional: Repeat steps 5 and 6 for all your anchors.8. Attach the collectedwascerts.jks file from the last anchor, or from your TADDM host if you do not

use the script on anchors, to your WebSphere access list entry as a truststore. The SSL type of this fileis JKS. Use the passphrase described in step 2.

Creating a single truststore manuallyTADDM can use only one truststore file for a single discovery. If you want to use certificates from severaltruststores, you must export those truststores to a single file. You can extract the certificates and addthem to the keystore and truststore files manually.

1. Extract all certificates from the common keystore or truststore for each server by completing thefollowing steps:a) In the WebSphere Application Server Admin Console, click Security > SSL certificate and key

management.b) Click Key stores and certificates.c) Click NodeDefaultTrustStore.d) Click Signer certificates.e) Select a signer certificate, and click Extract.


f) Enter a unique path and file name for the signer certificate.For example, enter C:\temp\signer1.arm.

g) Click OK.h) Repeat this procedure for each signer certificate in the truststore.i) Repeat this procedure for all servers that are to be discovered.

2. If you use the JKS truststores, add the exported signer certificates to the .jks files. To add them tothe default DummyServerTrustFile.jks and DummyClientTrustFile.jks files, complete thefollowing steps. If you use PKCS12 truststores, follow the same procedure for key.p12 andtrust.p12 files:a) To open iKeyman, from the WebSphere_Root/profiles/dmgr_profile/bin directory, runikeyman.sh, or ikeyman.bat.

b) Click Key Database File > Open.c) Select the DummyServerTrustFile.jks file from one of the following directories:

• WebSphere_Root/profiles/dmgr_profile/etc• WebSphere_Root/profiles/stand-alone_server_profile/etc

d) When prompted for a password, type WebAS.e) Click Add, and select one of the signer certificates that you extracted in step 1.f) Repeat the previous step for each signer certificate that you must add.g) Repeat this procedure to add the exported signer certificates to the WebSphere_Root/profiles/dmgr_profile/etc/DummyClientTrustFile.jks file.

3. Retrieve the client side SSL certificates from the WebSphere Application Server. If new certificates arenot generated, the default ones, DummyClientTrustFile.jks and DummyClientKeyFile.jks, ortrust.p12 and key.p12, are typically in one of the following directories:

• WebSphere_Root/profiles/dmgr_profile/etc• WebSphere_Root/profiles/stand-alone_server_profile/etc

The default passphrase for dummy files is WebAS.4. If you want to use different certificates, do not attempt to edit the certificates. Delete the old access

list entry and create a new one.

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

Note: The following properties do not apply to the script-based or asynchronous discovery mode, becauseWebSphereScriptSensor does not use them.

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

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

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

If you have a large WebSphere environment and require medium or deep discovery levels, you mightneed to increase the value so that the sensor has enough time to discover the environment.

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

com.collation.discover.agent.WebSphereVersionAgent.versionscript=sudoThis property can be enabled for access to the WebSphere versionInfo.sh file if the discovery userdoes not have access on the target WebSphere Application Server system.


Using the WebSphere seed sensor for z/OSTADDM does not support an operating system sensor for a z/OS system. To discover WebSphereresources on a z/OS system, the WebSphere sensor is enhanced to support discovery initiated from user-created seed files.

Because there is no z/OS system sensor, you must use the WebSphere Application Server seed utility forthe z/OS DLA. This utility creates an XML seed file from a z/OS IdML book. This file contains informationabout the WebSphere resources that you are trying to discover on the z/OS system.

After this seed file is created, on the next discovery, the WebsphereIdmlSeedSensor looks for z/OSWebSphere seed files on the TADDM server. If there are, it parses that seed file and create a realdiscovery seed file that is used to kick off the WebSphere sensor. The WebSphere sensor then does adeeper discovery of WebSphere on this z/OS system.

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

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

Before running the WebSphere seed sensor, complete the following steps:

1. Choose the appropriate method to create the WebSphere seed file:

• To discover WebSphere on a z/OS system using the Discovery Library Adapter, use the WebSphereApplication Server seed utility that generates the seed files automatically from the IdML bookscreated from the z/OS DLA. The utility is provided as a part of the z/OS DLA package.

For information about this utility, see the WebSphere Application Server discovery section of the DLAfor z/OS information center.

• To discover WebSphere on a non-mainframe system by manually creating the seed file, use thefollowing file naming conventions when creating the seed file:

– If you want the file to be included as part of the discovery, the file name must end with a .xmlextension.

– The file name must adhere to the following format:

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

An example is c1_0.0.0.0_2809.xml.

The following example shows the file format:

<IDML_WAS_SEED> <WAS_ROOT_DIR>/opt/WebSphere/AppServer</WAS_ROOT_DIR> <WAS_VERSION>6.0.2.7</WAS_VERSION> <SOAP_CONNECTOR_PORT>8880</SOAP_CONNECTOR_PORT> <RMI_CONNECTOR_PORT>2809</RMI_CONNECTOR_PORT> <JMX_LISTEN_IP_ADDRESS>0.0.0.0</JMX_LISTEN_IP_ADDRESS> <HOST_MAPPINGS> <HOST_MAPPING> <HOST_NAME>wasserver.company.com</HOST_NAME> <PRIMARY_IP_ADDRESS>0.0.0.0</PRIMARY_IP_ADDRESS> <IP_ADDRESS>0.0.0.0</IP_ADDRESS> </HOST_MAPPING> </HOST_MAPPINGS></IDML_WAS_SEED>

WAS_ROOT_DIRThe directory path where the WebSphere Application Server is installed.

WAS_VERSIONThe version of the WebSphere Application Server, which can be found in the product file in the<WebSphere Root Directory>/properties/version directory.


http://www-01.ibm.com/support/knowledgecenter/SSBH2C_7.2.2/com.ibm.taddm.doc_zosdla/c236521231.htm

SOAP_CONNECTOR_PORTThe port number is retrieved from the serverindex.xml file for theSOAP_CONNECTOR_ADDRESS endpoint name. For example, <WebSphere Root Directory>/profiles/<app server or dmgr>/conf/cells/<cell name>/nodes/<node name>If the resource is a deployment manager, use the serverindex.xml file with the followingvalue specified: serverType="DEPLOYMENT_MANAGER".If the resource is stand-alone component, use the serverindex.xml file with the followingvalue specified: serverType="APPLICATION_SERVER"

RMI_CONNECTOR_PORTThe 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_ADDRESSThe IP address that is used to connect through JMX. Typically this address is the same IPaddress as the WebSphere server.

HOST_MAPPINGSA list of mappings between the host name and IP address for the WebSphere Application Serveror Deployment Manager and each distributed Node Agent.

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

HOST_NAMEThe fully qualified domain name.

PRIMARY_IP_ADDRESSThe primary IP address that the host name resolves to.

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

2. Place the .xml files in the $COLLATION_HOME/var/dla/zos/was directory. If the directory doesnot exist, create the directory. The scope of discovery is controlled by the files in this directory. Ifdiscovery of a particular WebSphere server is no longer needed, the file must be removed from thisdirectory or renamed without the .xml extension.

3. Create a new sensor configuration file when you run the WebSphere seed sensor. Change the locationof 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 arelocated.

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

To run the WebSphere seed sensor, complete the following steps:

1. Start the TADDM server.2. Open the Discovery Management Console.3. Add the IP address of the server where the WebSphere seed file is located to a scope.4. In the Access List, add the access credentials of the server where the WebSphere seed file is located.5. If security is enabled for the WebSphere server being discovered, add the credential entry for the

WebSphere server. If you want to use the entry with a scope restriction, you must include the IPaddress of your WebSphere server in the discovery scope in addition to the IP address of the host,where the WebSphere seed file is located.

You also need the client-side SSL certificate when creating the Access List entry. This certificate mustbe 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 canbe used by TADDM. The JKS or PKCS12 file must then be used for the SSL settings in the TADDMWebSphere Access List entry for both keystore and truststore certificates.

6. Complete the following steps:

a. Configure the IdmlFileUDS sensor using the Discovery Management Console:

1) In the Discovery Profiles window, click IdmlFileUDS.2) Click New.3) Type the sensor configuration name and description.4) Select Enable Configuration.5) Double-click /data/latest/dist/var/dla/zos/was and type the location of 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:

• Anchor Sensor• Sensor name entered in step a. (The modified IdmlFileUDS sensor created previously.)• PortSensor• PingSensor• SessionSensor• GenericServerSensor• WebSphereIdmlSeedSensor• WebSphereCellSensor• WebSphereNodeSensor• 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 alladditional sensors.

c. Save the configuration file.7. Run the discovery and select the scope to include the server and the discovery profile that you created.

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

Sensor does not startProblem

The WebSphere Application Server sensor does not start.Solution

To determine why the WebSphere Application Server sensor does not start, validate the followingcriteria on your WebSphere server:

• The WebSphere process is running.• The command line is not truncated (the process that is running must match the template for the

WebSphere Application Server).

For Windows 2003/2008, Linux, Solaris, AIX, and Linux on System z operating systems, thecommand line must contain the word WsServer.


• The WebSphere Application Server was started as a service (on Windows 2000), or as a service orfrom the command line (Windows 2003 or Windows 2008).

If none of the preceding items appear to be the cause, check the system log and the WebSphereApplication Server start logs for error messages.

WebSphere servers or nodes cannot be discoveredProblem

Some WebSphere servers or nodes cannot be discovered.Solution

When the WebSphere server or node to be discovered is configured to use FQDN instead of plain IPaddress as its bootstrap address, the TADDM server must have access to a DNS server that is able toresolve that FQDN. Otherwise the information about this particular server or node cannot bediscovered, even if the target scope is defined using the IP address.

Discovery of WebSphere Application Server is not loggedProblem

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

SolutionThe log messages are placed in the following log files, where hostname is the fully qualified domainname of the TADDM server:

• local-anchor*.hostname.WebSphereAgent.log• local-anchor*.hostname.WebSphereNodeSensor.log

Errors when security is enabled on WebSphere Application ServerProblem

The following types of error messages are displayed:

• ERROR cdb.WebSphereAgentDelegate - [WebSphereAgentDelegate.E.1]discover() failed with exception : java.lang.Exception: Unable to connect to the WebSphere server at 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...

• 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 insufficientor empty credentials.

These errors can occur for any of the following reasons:

• No credentials exist in the access list for the WebSphere Application Server.• In the credentials for the WebSphere Application Server, the certificates are not correct or have not

been entered through the access list.• In the credentials for the WebSphere Application Server, the password is incorrect.

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

Failure to make a JMX connectionProblem

The following type of error occurs:


Sensor failed in remote server:Unable to connect to WebSphere server at 10.0.1.69:8880 - ADMC0016E:Could not create SOAP Connector to connect to host 10.0.1.69 at port 8880

This type of error indicates the following problems:

• A missing or incorrect certificate or an incorrect user ID and password. The following exampleshows 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]

• A firewall that is preventing a connection to the WebSphere Application Server through the SOAPport.

• The WebSphere Application Server might not be in a good state, even though the process shows upin 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.

SolutionUse either of the following solutions:

• Run one of the following programs, which tests the JMX connection to verify credentials andconnectivity:

– For Linux, AIX, and Linux on System z operating systems: $COLLATION_HOME/bin/testwasconnection.sh. Instructions for running this program are in thetestwasconnection.sh file.

– For Windows systems: %COLLATION_HOME%\bin\testwasconnection.bat. Instructions forrunning this program are in the testwasconnection.bat file.

• Make sure that your access list is defined correctly. If you discover WAS on z/OS and you want touse an access list entry with a scope restriction, you must include the IP address of your WebSphereserver in the discovery scope in addition to the IP address of the host where the WebSphere seedfile is located.

Sensor fails on a JMX queryProblem

The sensor fails on a JMX query with the following message:

failed on JMX query--check server health and retry

This error indicates that the configuration setup might be corrupted.Solution

Check the logs to see what is being queried and whether that value is readable in the WebSphereApplication Server console. This error usually occurs because discovery is run overnight, andWebSphere Application Servers are down for maintenance reasons. In this case, restart the server,and try the discovery again.

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

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

The database tuning script was not run before TADDM schema creation. Before creating the TADDMschema, run the following database tuning script:

• For non-Windows systems:


$COLLATION_HOME/bin/gen_db_stats.jy

• For Windows systems:

%COLLATION_HOME%\bin\gen_db_stats.bat

WebSphere Application Server is downProblem

The WebSphere Application Server is down for one of the following reasons:

• TADDM runs when a WebSphere Application Server is in maintenance, and a discovery does notcomplete. The local-anchor*.hostname.WebSphereAgent.log file or local-anchor*.hostname.WebSphereNodeSensor.log file might display the following errormessage:INFO cdb.AnchorServer[main] - [AnchorServer.I.0] server no longeraccepting new connections

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

SolutionVerify that the WebSphere Application Server is functioning properly.

Sensor does not show as much data as it did in previous releases of TADDMProblem

The Details window for WebSphere cells, nodes, and servers does not show as much detail as it did inprevious TADDM releases, and many of the tabs in the window have no data.

SolutionTADDM implements the following discovery levels:

• Shallow• Medium• Deep

The default discovery level for the WebSphere Application Server sensor is shallow.

To obtain more detail about the WebSphere Application Server, create a discovery sensorconfiguration for the WebSphereCellSensor sensor, and in the Sensor Configuration window. Set thevalue of the mediumDiscoveryLevel property or the deepDiscoveryLevel property to true.

WebSphere sensor fails during WebSphere discovery on an AIX operating systemdue to problems with the AIX ps commandProblem

On some AIX operating systems, running the UNIX ps command returns truncated Java CLASSPATHstrings. The strings are not recognized by the TADDM WebSphere sensor, resulting in a faileddiscovery.

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

Message CTJDT0736W is shownProblem

Insufficient credentials exist in the access list for the Secure Shell (SSH) protocol or WindowsManagement Instrumentation (WMI) on the host system where the distributed node is running.The computer system credentials for this host system are used to retrieve information to populate thehost for the node and server configuration items on that system.


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

WebSphere sensor fails and the following message is displayed: CTJTD0692EProblem

While attempting to discover a distributed WebSphere cell, the WebSphere sensor fails with thefollowing message:

CTJTD0692E The distributed cell deployment manager bind address is notfound for the following cell:etabsap1TCell

SolutionDiscoveries involving the sensors related to WebSphere Deployment Manager must have a workingDNS. As a workaround, changecom.collation.platform.os.disableRemoteHostDNSLookups to true, and ensure that theTADDM server always has the correct DNS search path.

WebSphere sensor fails and the following message is displayed: CTJTD3021EProblem

The WebSphere sensor fails with the following message:CTJTD3021E The sensor fails in a remote server : CTJTD2120E An error has occurred in the discovery process.:CTJTD0775E A connection to the WebSphere server is not available: << ip address of IBM WebSphere application server >> - ADMC0016E: The system cannot create a SOAP connector to connect to host << ip address of IBM WebSphere application server >>

SolutionVerify that the problem is with the SSL support in the WebSphere client code. To verify, ensure that theWebSphere access list entry for this WebSphere Server is first in the access list (before any otherWebSphere credentials). If the discovery is successful, import all the WebSphere certificates from thedifferent servers into one truststore. Having multiple access list entries with different user IDs andpasswords is acceptable. However, all the access list entries must specify the same truststore, whichcontains all the certificates.

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

WebSphere JDBC driver sensor does not startProblem

The WebSphere JDBC driver sensor does not start.Solution

To establish why the WebSphere JDBC driver sensor does not start, ensure that the followingconditions have been met:

• A user profile for Level 3 discovery has been created and the WebSphere JDBC driver sensor isenabled.

• Deep discovery is enabled for the WebSphere cell sensor.

WebSphere JDBC driver sensor cannot connect to the target host and the followingmessage is displayed: CTJTD0796EProblem

During the discovery, the WebSphere JDBC driver sensor cannot establish a connection with targethost and the CTJTD0796E error message is displayed.

SolutionThe following situations are possible reasons for this error:


• SSH connection could not be established with the host.• A connection with the host was established, but the user did not have the appropriate privileges to

run the WebSphere setupCmdLine script.• 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 userspecified in the WebSphere SSH access list entry has the appropriate privileges to run the WebSpheresetupCmdLine script.

If the sensor fails and the warning CTJTD0799W is displayed in the log files, ensure that the userspecified in the WebSphere SSH access list entry has the appropriate privileges to run the Javacommand.

Some JDBC dependencies are not created between a WebSphere server anddatabase serversProblem

TADDM discovers both the WebSphere server and a related database server but does not create arelation between them. Such a relation is based on the JDBC connection properties that are definedon the application server.

Solution

The problem might be a result of one of the following issues:

• JDBC connectivity details are gathered by deep level discoveries only. Ensure that the discoveryprofile for the WebSphere sensor is configured for that level of discovery.

• The dependencies are created by the JDBCDependencyAgent that runs in the Dependency topologyagent group. Ensure that the agent is run after the discovery of the WebSphere servers.

• The JDBCDependencyAgent processes only the recently discovered application servers. If somedependencies are still missing after the agent has run, rediscover the WebSphere servers, and waitfor the topology agents to run again.

• Ensure that the database server is one of those that supports the creation of transactionaldependencies between it and the WebSphere application server. The following databases aresupported:

– Oracle– IBM DB2– Microsoft SQL Server– Sybase

WebSphere sensor fails when the TADDM server is running Red Hat Enterprise Linux6Problem

WebSphere sensor fails when the TADDM server is running Red Hat Enterprise Linux 6. The followingerrors might be displayed:

CTJTD3021E The sensor fails in a remote server

CTJTD2015E There is a local anchor sensor failure


SolutionIn the /etc/security/limits.d/90-nproc.conf configuration file, comment out the followingline:

* soft nproc 1024

After you have updated the configuration file, you must restart the TADDM server.

Only placeholder objects are stored after a script-based discoveryProblem

After you run a successful WebSphereScriptSensor discovery, all stored objects are marked asplaceholders and contain few details.

SolutionPlaceholder objects are created by the WebSphereScriptSensor when a discovery target is aWebSphere Application Server node in a distributed cell other than the management cell (a DMGR'snode). To obtain more detailed information about the placeholder model objects, run a discovery ofthe host with the DMGR.

IBM WebSphere eXtreme Scale cache sensorThe IBM WebSphere eXtreme Scale cache sensor discovers IBM WebSphere eXtreme Scale caches andsome of their components.

The sensor discovers the following elements for the eXtreme Scale cache:

• The name of the cache• A list of nodes on which the cache resides

The sensor discovers the following elements for each eXtreme Scale node:

• The name of the node• The host name of the node• The contents of the main configuration file• The contents of the orb.properties configuration file for the JVM that runs this node and version of

this JVM• The contents of .xml, .sh, .props, and .properties files that are in the same directory as mainconfiguration file

Sensor name that is used in the GUI and logsWebSphereXSCacheSensor

PrerequisitesIBM 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 issuesThe user must have permission to perform the following tasks:

• Get the complete list of processes, including Java virtual machine (JVM) processes, running on thetarget system.

• Read the configuration file specified by the -objectgridfile parameter, typically objectGrid.xml.• 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.


• Run the JVM that runs the eXtreme Scale node with the -version parameter, to get runtimeenvironment version information.

• Read the orb.properties configuration file, which is in the lib directory of the JVM.


• Only those eXtreme Scale nodes that are using separate JVMs as containers for eXtreme Scale cachesare discovered. Caches that use special web applications as containers for eXtreme Scale nodes are notdiscovered.

• JVMs that provide catalog services for eXtreme Scale nodes are not discovered.• If more than one JVM process is started with the same node name and the same copy of theconfiguration file specified by the -objectgridfile parameter, the sensor does not recognize thatthey are separate nodes, and the nodes are merged.

• The sensor looks for configuration files only in the same directory as the configuration file specified bythe -objectgridfile parameter, and its subdirectories. Only files with one of the followingextensions are recognized:

– .xml– .sh– .props– .properties

You cannot configure the file extension recognized.• The sensor does not parse the configuration files, but captures the entire contents of each file.• When checking the -objectgridfile parameter, the sensor ignores case.

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

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.app.JVM

ExecutableNameJVMVersionPublisherSoftwareVersion

websphere.WebSphereXSCache

• Name

websphere.WebSphereXSCacheNode

• Name• Host



1. Select ComputerSystem as the Component Type.


2. Specify the access information (user name and password) that TADDM must use for authentication tothe target computer system.

IBM WebSphere Message Broker sensorThe IBM WebSphere Message Broker sensor discovers WebSphere Message Broker attribution at brokerinstance, configuration, and application levels for Windows and UNIX.

Sensor name that is used in the GUI and logsMBServerSensor

PrerequisitesThe TADDM server requires the following login information:

System login with ability to discover the target computer.

You must be authorized to run mqsiprofile command.

LimitationsAfter a discovery using the IBM WebSphere Message Broker sensor, some attribute values in the Detailspane remain empty because the sensor does not populate all of the Message Broker elements. You canfind the full list of discovered classes and attributes in the sensor data dictionary. To populate the missingattribute values, you can use other data producers, such as Discovery Library Adapters (DLAs), or customserver extensions that extend the TADDM discovery capabilities.


• messaging.mb.MBBroker• messaging.mq.MQQueueManager• messaging.mb.MBExecutionGroup• messaging.mb.MBHTTPListenerProperties• messaging.mb.MBHTTPConnectorProperty• messaging.mb.MBHTTPSConnectorProperty• messaging.mb.MBHTTPListenerProperty• messaging.mb.MBBrokerSecurity• messaging.mb.MBBrokerProfile• messaging.mb.MBMessageFlow• messaging.mb.MBMessageFlowNode• messaging.mb.MBBarFile• messaging.mb.MBProperty


Configuring the discovery profileIf you want to change the discovery level, update the discovery profile for the IBM WebSphere MessageBroker sensor.

To change the default the discovery level for this sensor, complete the following steps:

1. In the Discovery Profiles window, click New.


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

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

select one of the following choices:

• To use OS credentials to conduct discovery, double-click the value for useHostAuth and changefrom false to true

• To discover WebSphere message flow nodes attributes, double-click the value for useNodeLevel andchange from false to true

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

For more information about Discovery Profiles, see the Using discovery profiles topic in the TADDM User'sGuide.

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


1. Select Messaging Servers as the Component Type.2. Select WebSphere Message Broker as the Vendor.3. Specify the following required information:

• User name• Password

You must be authorized to run mqsiprofile command.



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

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

com.collation.platform.os.AixOs.forcedServerList=bipbroker

This property forces the bipbroker process to start the sensor on AIX platform.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM WebSphere Message Broker sensor andpresents solutions for those problems.


The WebSphere Message Broker sensor does not start.Solution

Make sure that the bipbroker process name is added to thecom.collation.platform.os.UnixOs.forcedServerList property in the collation.propertiesfile.


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

Sensor name that is used in the GUI and logsMQServerSensor

Security issuesThe TADDM server requires the following login information:

• System login with ability to discover the target computer.• For the WebSphere MQ server on a UNIX system, the WebSphere MQ user login and password used to

log on to the MQSC console.


• app.messaging.mq.MQChannel• app.messaging.mq.MQClientConnectionChannel• app.messaging.mq.MQCluster• app.messaging.mq.MQClusterReceiverChannel• app.messaging.mq.MQClusterSenderChannel• app.messaging.mq.MQInstallation• app.messaging.mq.MQListener• app.messaging.mq.MQNameList• app.messaging.mq.MQQueueManager• app.messaging.mq.MQRequesterChannel• app.messaging.mq.MQServerChannel• app.messaging.mq.MQTCPListener• app.ProcessPool

Asynchronous and script-based discovery supportThe IBM WebSphere MQ Server sensor supports only script-based and asynchronous discovery. It doesnot run in regular discoveries.

Sensor configuration requirementsFor script-based and asynchronous discovery, the sensor requires no configuration.

LimitationsApplication descriptor discovery is not supported.


Configuring the access listDescribes the access details required for both UNIX and Windows installations.

Prerequisites


For Windows systems, the user must be a member of the Windows Admin Group to run the runmqsccommand.

For UNIX systems, the WebSphere MQ user has privileges to run the runmqsc command.

Configure the access list as follows:

1. Select Messaging Servers as the Component Type.2. Select WebSphere MQ as the Vendor.

Windows systems require the following information:

• User name• Password



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

com.collation.topobuilder.mq.clusterrelations=trueThis property enables the building of dependencies based on cluster membership. Every QueueManager in the cluster has two dependencies (one as a source and one as a target) to every otherQueue Manager in the same cluster.If not set, the default value is false.

com.collation.topobuilder.mq.channelrelations=trueThis property enables the building of dependencies based on sender-receiver channel names. If notset, the default value is false.Limitation: This capability is available only if the channel names contain both the name of the sourcemanager and the target manager. Otherwise, it is not possible to build a regular expression for thecom.collation.topobuilder.mq.channelnaming property.

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

com.collation.topobuilder.mq.channelnaming=<REGULAR EXPRESSION>Allows you to specify custom channel naming rules for creating channel dependencies.REGULAR_EXPRESSION must return two named groups:

• The first matches the source manager name.• 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 sourcequeue manager name is not compared with the sender channel parent queue manager name in thatcase.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=trueSets the QueueManager name; the default value is false.<FQDN>:<QUEUE_MANAGER_NAME> - First non-empty Fully Qualified Domain Name (FQDN) or IPfrom the first listening MQListener is used

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


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

com.collation.discover.agent.MQQueueManager.UseEmptyHostName=trueIf the FQDN is not present, the first non-empty FQDN (or IP) taken from the LOCLADDR attribute of theClientConnection is used. The default value is false.<QUEUE_MANAGER_NAME> - The QueueManager name without the FQDN is used.

com.collation.topobuilder.mq.removerelationsIf not set, the default value is false. If set to true, dependencies for the WebSphere MQ queuemanager are removed if the state is other than running.

If none of the preceding properties are set to true (UseListenningIp or UseIpFromConnections did notresolve the FQDN), the parent host FDQN is used.

<HOST_FQDN>:<QUEUE_MANAGER_NAME>

The following properties are used to specify that the sensor should use the sudo command when runningMQ commands on the server.

com.collation.discover.agent.MqServerAgent.versionCommand=sudo -u userSpecifies that the sensor should use sudo with the specified user name when running the MQversion command.

com.collation.discover.agent.MqServerAgent.statusCommand=sudo -u userSpecifies that the sensor should use sudo with the specified user name when running the MQ dspmqcommand.

com.collation.discover.agent.MqServerAgent.mqscCommand=sudo -u userSpecifies that the sensor should use sudo with the specified user name when running the MQrunmqsc 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

Troubleshooting the sensorThis topic describes common problems that occur with the IBM WebSphere MQ Server sensor andpresents solutions for those problems.


The WebSphere MQ Server sensor does not start.Solution

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

Sensor starts, but it does not discover all of the information through IBM TivoliMonitoring discoveryProblem

Discovery of the WebSphere MQ Server sensor through IBM Tivoli Monitoring ends successfully, butnot all of the information is discovered.

SolutionMake sure that on target host, the user, under which the IBM Tivoli Monitoring agent is running, isadded to the mqm group.


iPlanet server sensorThe iPlanet server sensor discovers iPlanet Web servers.

Sensor name that is used in the GUI and logsIPlanetServerSensor

PrerequisitesThe TADDM service account should have:

• Execute permissions on the iPlant binary, either ns-httpd or webserd.• Read access to the iPlanet configuration files


• app.AppConfig• app.SoftwareContainer• app.SoftwareModule• app.StaticContentModule• app.web.CGIScript• app.web.iplanet.IPlanetJSP• app.web.iplanet.IPlanetJVMSettings• app.web.iplanet.NSAPIPlugin• app.web.iplanet.IPlanetServer• app.web.iplanet.IPlanetServlet• app.web.iplanet.IPlanetSSLSettings• app.web.iplanet.IPlanetVirtualHost• app.web.iplanet.IPlanetWebContainer• app.web.iplanet.WebLogicConnection• app.web.WebConnection• sys.DataFile sys.Directory

JBoss server sensorJBoss sensor discovers version of a JBoss installation and collects data for the server. It can be used todiscover JBoss AS versions 4, 5, and 6.

Sensor name that is used in the GUI and logsJBossVersionSensor, JBossSensor

PrerequisitesThe following prerequisites must be met:

• Discovery of the computer system must succeed.• JMX must be enabled on the JBoss server.• If the JMX is protected by password, the credentials must be entered in the access list.


The JBoss sensor requires JAR files that are part of the JBoss Server installation. You must copy the JARfiles to the following directories ($COLLATION_HOME) on the TADDM server.

For JBoss AS 4:

• lib/jboss/402/jbossall-client.jar, lib/jboss/402/jnpserver.jar• lib/jboss/402/jboss-jmx.jar

For JBoss AS 5:

• lib/jboss/5/jboss-client.jar• lib/jboss/5/jnp-client.jar• lib/jboss/5/jboss-logging-spi.jar• lib/jboss/5/jboss-security-spi.jar• lib/jboss/5/jboss-common-core.jar• lib/jboss/5/jboss-javaee.jar• lib/jboss/5/jmx-invoker-adaptor-client.jar• lib/jboss/5/jbosssx-client.jar• lib/jboss/5/jboss-integration.jar• lib/jboss/5/jboss-serialization.jar• lib/jboss/5/jboss-remoting.jar• lib/jboss/5/jboss-jca.jar

For JBoss AS 6:

• lib/jboss/6/jboss-client.jar• lib/jboss/6/jnp-client.jar• lib/jboss/6/jboss-logging.jar• lib/jboss/6/jboss-security-spi.jar• lib/jboss/6/jboss-common-core.jar• lib/jboss/6/jmx-invoker-adaptor-client.jar• lib/jboss/6/jbosssx-client.jar• lib/jboss/6/jboss-integration.jar• lib/jboss/6/jboss-serialization.jar• lib/jboss/6/jboss-remoting.jar• lib/jboss/6/jboss-jca.jar

LimitationsImportant: JBoss AS 6 is supported from TADDM 7.2.2 Fix Pack 1.

If a discovery of a JBoss version via a JMX connection fails, JBossVersionSensor uses the SSH session fordiscovery. The sensor does not discover the content of JBoss and the model objects are not created.

For JBoss ManagedConnectionFactories, the JDBC XA data source properties are not discovered by thesensor. As a result, the transactional dependencies between JBoss server and the database servers thatare denoted by such data sources are not created.


• app.AppServer• app.j2ee.J2EEServer


• app.j2ee.jboss.JBossCluster• app.j2ee.jboss.JBossDomain• app.j2ee.jboss.JBossJMSServer• app.j2ee.jboss.JBossServer

Configuring the sensorBefore you run a discovery of the JBoss installation, you must configure the JBoss server sensor.


You need the following information:

• The access list entry for the computer system running the JBoss server.• The access list entry for the JBoss server JMX console, if password protected.



com.ibm.cdb.discover.jbossversion.sockettimeoutThis property specifies a socket timeout value (in milliseconds) for JBossVersionSensor.

Troubleshooting the sensorThis topic describes common problems that occur with the JBoss sensor and presents solutions for thoseproblems.

JBossVersionSensor does not startProblem

The JBossVersionSensor does not start.Solution

• Go to http://ipaddress:webport/jmx-console and scroll through the console to see if theJBoss server JMX console is enabled.

• Ensure that lsof works properly.

JBoss libraries not foundProblem

When you run the sensor, the JBoss libraries not found message is displayed.Solution

Ensure that the JBoss JAR files for your JBoss server version are in the dist directory, and that readaccess is enabled for User.

Some JDBC dependencies are not created between a JBoss server and databaseserversProblem

TADDM discovers both the JBoss server and a related database server but does not create a relationbetween them. Such a relation is based on the JDBC connection properties that are defined on theapplication server.

Solution



• The dependencies are created by the JDBCDependencyAgent that runs in the Dependency topologyagent group. Ensure that the agent is run after the discovery of the JBoss servers.

• The JDBCDependencyAgent processes only the recently discovered application servers. If somedependencies are still missing after the agent has run, rediscover the JBoss servers, and wait for thetopology agents to run again.

• Ensure that the database server is one of those that supports the creation of transactionaldependencies between it and the JBoss application server. The following databases are supported:


JBossVersionSensor fails with the error message "CTJTD0030E An error occurredwhile executing ./run.bat -V".Problem

JBossVersionSensor fails and the following error message can be found in logs:

• For JBoss AS on Windows:

ERROR sensor.JBossVersionSensor - CTJTD1573E An error occurred while executing ./run.bat -V: com.collation.platform.os.OsException: '.' is not recognized as an internal or external command,.

• For JBoss AS on Linux:

ERROR sensor.JBossVersionSensor - CTJTD1573E An error occurred while executing ./run.sh -V: com.collation.platform.os.OsException: '.' is not recognized as an internal or external command,.

SolutionJBossVersionSensor was unable to detect the version of JBoss AS because the full path to therun.bat or run.sh script was not provided before the application server was started. Copy therequired JBoss libraries (JAR files) to the $COLLATION_HOME/lib/jboss directory to enable aversion detection via JMX. Without these libraries, the JBoss server sensor does not store any modelobjects. See the “Prerequisites” on page 86 section to learn which libraries must be copied.

JBoss Application Server 7 sensorThe JBoss Application Server 7 sensor discovers JBoss AS configuration for JBoss AS 7.0 and later.

The sensor discovers JBoss servers that are run both as stand-alone servers and in a managed domain.Every host that belongs to a managed domain is discovered independently, so to get a full picture of aJBoss topology, a discovery must be run against each of the hosts. When an environment is discovered forthe first time, it is advised to start with the discovery of a host, which acts as a JBoss domain controller,and then run a discovery of domain members.

Sensor name that is used in the GUI and logsJBoss7Sensor

PrerequisitesAn OS user that runs a discovery must have the read access to JBoss configuration files and deploymentcontent. The user must also be able to run java, otherwise the deployment descriptors are notdiscovered.


Limitations• Applications and modules that are deployed to a stand-alone server by placing the deployment content

in the deployments folder (file system deployments) are not discovered by the sensor. Only applicationsand modules that are deployed by using the JBoss AS management APIs (the command line or webinterface) are supported.

• The deployment type recognition relies on searching for specific descriptor files in the deploymentcontent. If none of these descriptors is found, a general type J2EEDeployedObject is assigned to amodel object that is stored by the sensor.

Model objects createdThe sensor creates model objects of the following types:

• app.j2ee.jboss.JBossDomain• app.j2ee.jboss.JBossHost (only for managed domains)• app.j2ee.jboss.JBossCluster (representing server groups in a JBoss managed domain)• app.j2ee.jboss.JBossServer• app.ConfigFile• app.j2ee.J2EEDeployedObject (and its subtypes)

JDBC data sources are stored as extended data of JBossClusters (for a managed domain) or JBossServer(for a stand-alone server). Deployment descriptors are stored as extended data of J2EEDeployedObjects.

Configuring the sensorBefore running a discovery, you must configure the JBoss Application Server 7 sensor.

The JBoss Application Server 7 sensor has the following configuration options. If you want to changethese options, create a custom sensor configuration. See the Creating discovery profiles topic in theTADDM User's Guide.

extractAllXmlDescriptorsThe default value of this property is true.If this property is set to true, the sensor discovers all files with the .xml extension from the META-INF and WEB-INF directories of applications or modules that are deployed on JBoss. If this propertyis set to false, the descriptorsToExtract property is used.

descriptorsToExtractThis property specifies a space-separated list of files, which are to be discovered for JBossdeployments when the extractAllXmlDescriptors property is set to false. For example, META-INF/application.xml WEB-INF/web.xml. Wildcard characters are not allowed.

extractSubmodulesThe default value of this property is false.If this property is set to true and if a deployment is a Java Platform Enterprise Edition application in aform of an enterprise archive (EAR), the sensor discovers descriptors from this deployment and itsmodules, for example from JAR or WAR files. If this property is set to false, the descriptors from thesubmodules of the deployment are not discovered.

Note: To discover modules of an enterprise archive (EAR), its META-INF/application.xml must beextracted. It means that either the extractAllXmlDescriptors property must be set to true, orthe value of the descriptorsToExtract property must include META-INF/application.xml.

tagsToMaskThe default value of this property is 'password'.This property specifies a space-separated list of XML tags. Any text content of these tags in files whichare discovered is masked with asterisks.


Configuring the collation.properties file entriesYou can configure the collation.properties file entries to adjust commands that the JBossApplication Server 7 sensor uses.

com.ibm.cdb.discover.sensor.app.j2ee.jboss7.java or com.collation.discover.agent.command.javais a java executable file. If this command is not set, the sensor uses the default java on a discoveredhost (the one, which is present in the system $PATH). If it fails, java, which runs the discoveredJBoss AS, is used instead.

com.ibm.cdb.discover.sensor.app.j2ee.jboss7.pwdx or com.collation.discover.agent.command.pwdxreports current working directory of a process (for UNIX systems only).The default value is pwdx.

com.ibm.cdb.discover.sensor.app.j2ee.jboss7.ps.full orcom.collation.discover.agent.command.ps.full

lists all running processes in a full format (for UNIX systems only).The default value is ps -ef, except for the Solaris operating system, for which the default valueis /usr/ucb/ps auxww.

Configuring for asynchronous discoveryYou can modify the default settings if you want to run the JBoss Application Server 7 sensor in theasynchronous discovery mode.

Custom sensor configurations are not read when an asynchronous discovery package is prepared. If youneed to use a configuration other than the default one, modify the configuration in the$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.j2ee.jboss7_<version>/plugin.xml file.

Troubleshooting the sensorThis topic describes common problems that occur with the JBoss Application Server 7 sensor andpresents solutions for those problems.

A managed domain is duplicatedProblem

When many hosts that belong to the same JBoss managed domain are discovered simultaneously forthe first time, duplicates might be created in the TADDM database.

SolutionRun a discovery of the JBoss domain again. Duplicates are merged.To avoid such problem in future, discover a host, which acts as a JBoss domain controller first, andthen run a discovery of domain members.

Deployments, or JDBC data sources, or both, are not discoveredProblem

Not all deployments, or JDBC data sources, or both, are present in the TADDM database after somehosts that belong to a managed JBoss domain are discovered.

SolutionAlthough JBoss AS propagates deployments and JDBC data sources across a managed domainautomatically, the comprehensive information about them might be available only on a host that actsas a JBoss domain controller. To get a complete picture of a JBoss environment, all hosts, whichconstitute the domain must be discovered, especially the domain controller.

Modules of an EAR deployment are not discoveredProblem

A Java Platform, Enterprise Edition application in a form of an enterprise archive (EAR) is deployed toJBoss AS, but the sensor does not discover modules of the application.


SolutionConfigure the sensor so that the META-INF/application.xml descriptor is collected. See“Configuring the sensor” on page 90.

Some JDBC dependencies are not created between a JBoss server or server groupand database serversProblem

TADDM discovers both the JBoss server or server group and a related database server but it does notcreate a relation between them. Such relation is based on JDBC connection properties that aredefined on the application server.

SolutionThe problem might be a result of one of the following issues:

• The dependencies are created by the JDBCDependencyAgent that runs in the Dependency topologyagent group. Ensure that the agent is run after the discovery of the JBoss AS.

• The JDBCDependencyAgent processes only the recently discovered application servers. If somedependencies are still missing after the agent has run, rediscover the JBoss environment, and waitfor the topology agents to run again.

The JBoss Application Server 7 sensor does not startProblem

Although JBoss AS is started, the JBoss 7 Application Server sensor is not triggered.Solution

If a JBoss stand-alone server, or a JBoss host controller listens only on a loopback address and thecom.collation.platform.os.ignoreLoopbackProcesses=true property is set in TADDM, theserver process is ignored, and the sensor does not start. Change the value of the property to falsefor the JBoss host, which was not discovered, in the following way:

com.collation.platform.os.ignoreLoopbackProcesses.x.x.x.x=false

where x.x.x.x is the IP address of the discovery target.

JBoss servers belonging to a JBoss domain are getting over merged or only JBossserver of single host is saved

ProblemWhen discovery is run for multiple members of a single JBoss domain server, then after discoveryends, JBoss servers belong to only one of the multiple JBoss host discovered are saved.

SolutionThe problem is resolved in TADDM 7.3.0.6 with following conditions:

• Only one discovery server at a time should be running JBoss7Sensor for targets that are members ofa single JBoss Domain server. In case of load balanced discovery, this means that user should putall their JBoss target which are under a single JBoss domain server in same scope set to use thissensor, i.e. the targets should not be in different scope sets of a scope group to prevent them beingrun parallelly in load balanced discovery

CustomTemplateSensor defined on JBoss7Sensor causes JBoss server over merges

ProblemWhen we discover JBoss Server deployed in domain mode and profile includes aCustomTemplateSensor in which a template is defined which takes JBossDomain object from a


JBoss7Sensor and produces same type enriched object, then over merging of JBoss Server occurs.Only JBoss servers belonging to one random host are saved.

SolutionThe problem is resolved in TADDM 7.3.0.6 with following conditions:

• For a target, both sensors - JBoss7Sensor and JBossSensor should not get invoked. They may be indiscovery profile but if both gets invoked then over merging will still occur in case ofCustomTemplateSensor defined on JBoss7Sensor result

Kernel-based virtual machine sensorThe Kernel-based virtual machine sensor uses the libvirt library to discover the KVM supervisor withthe list of managed virtual machines.

Sensor name that is used in the GUI and logsKvmSensor

PrerequisitesThe libvirt daemon must be running on a target KVM host.

To avoid duplicates that are created by the Linux computer system sensor and the KVM sensor, you mustinstall DMI decode on each of guest computer systems.


• KVM• L2Interface• ComputerSystem• StoragePool• StorageVolume• CPU


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

The following property specifies that the sensor uses sudo to elevate privileges when it runs the KVMvirsh command:

• com.collation.discover.agent.kvm.systemcommand.Linux=sudo

You can scope this property to a specific IP address, as in the following example:

com.collation.discover.agent.kvm.systemcommand.Linux.192.168.1.1=sudo

Specify the sudo option for an operating system only if it is required for all systems that use thatoperating system. Otherwise, specify the option only for the specific IP addresses where the sudocommand is configured.

On the target systems that require the privilege escalation, configure the sudo command with theNOPASSWD option. Otherwise, the discovery hangs until the TADDM server times out.


Configuring the discovery profileTo change the discovery level, update the discovery profile for the KVM sensor. You can disable thediscovery of non-running guests to discover only those servers that are running.

1. From the Discovery Management Console, click the Discovery Profiles icon.2. In the Discovery Profiles window, click New.3. In the Create New Profile window, type the profile name, description, and click OK.4. In the list of sensors, click KVMSensor, and click New.5. In the Create Configuration window, type the name and description for your configuration of the KVM

sensor, and select the Enable Configuration check box.6. In the Configuration section of the Create Configuration window, to configure the sensor to discover

only the servers that are running, click discoverNonRunningGuests. Then double-click the Value fieldin the row, and type false.

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

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

Sensor name that is used in the GUI and logsMSClusterSensor

PrerequisitesThe MS Cluster sensor requires:

• Successful discovery of Windows computer systems• The Cluster Server ClusSvc service, must be running• Using the TADDM Windows Management Instrumentation (WMI) provider, WMI read access to theroot/mscluster namespace must be granted. If the discovery of the Windows computer systemssucceeded, this WMI read access is granted by default. Administrative-level access is preferable.

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

Model objects with associated attributesThe MS Cluster sensor creates model objects with associated attributes. The attributes indicate the typeof information that the sensor collects about Microsoft Server clusters in your IT environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.app.MsFailoverCluster.MsCluster

• CrossSubnetDelay• CrossSubnetThreshold• DefaultNetworkRole• Description• DisableGroupPreferredOwnerRandomization


• Domain• EnableEventLogReplication• HangRecoveryAction• HangTimeout• InternalNetwork• LogLevel• LogSize• MaintenanceFile• MaxNumberofNodes• MaxQuorumArbitrationTime• MinQuorumArbitrationTime• Name• Nodes• PlumbAllCrossSubnetRoutes• PublicNetworks• QuorumLogFileSize• QuorumPath• QuorumType• RegroupOpeningTimeout• RegroupPruningTimeout• RegroupStageTimeout• RegroupTick• RequestReplyTimeout• ResourceDllDeadlockPeriod• ResourceGroups• Resources• SameSubnetDelay• SameSubnetThreshold• SecurityLevel• WitnessDatabaseWriteTimeout• WitnessRestartInterval

app.MsFailoverCluster.MsClusterNode

• Description• EnableEventLogReplication• InitialLoadInfo• LastLoadInfo• Name• NodeHighestVersion• NodeLowestVersion• System

app.MsFailoverCluster.MsClusterResource

• AppServers• CryptoCheckpoints


• DeadlockTimeout• DebugPrefix• DeleteRequiresAllNodes• DependsOnResources• Description• HasSeparateMonitor• IpAddresses• IsAlivePollInterval• IsCoreResource• IsLocalQuorumCapable• IsPersistentState• IsQuorumCapable• LooksAlivePollInterval• Name• PendingTimeout• RegistryCheckpoints• RestartAction• RestartDelay• RestartPeriod• RestartThreshold• RetryPeriodOnFailure• Type

app.MsFailoverCluster.MsClusterResourceGroup

• AntiAffinityClassNames• AutoFailbackType• Description• FailbackWindowEnd• FailbackWindowStart• FailoverPeriod• FailoverThreshold• IsPersistentState• Name• Parent• Resources



A domain level account that is a member of the administrators group is required. To configure the accesslist, complete the following steps:

1. Select ComputerSystem (Windows) as the Component Type.


2. Specify the access information (user name and password).

An account with administrator privileges must be used.



com.ibm.cdb.topomgr.topobuilder.agents.MSClusterAgent.setComputerSystemMSClusterRel=false

This property specifies whether MS Cluster Topology Builder Agent sets the relationship betweenComputerSystem and MSCluster. If this property is set to true, the relationship is set.The default value is false.

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

WMI service crashesProblem

WMI service crashes on target during discovery.Solution

Ensure that all WMI-related fixes, including fix KB933061, are applied on the target system. Ifproblems persist, use the following Microsoft utilities to troubleshoot WMI problems:WMIDiag

The WMIDiag utility is available at the following Web site: https://www.microsoft.com/en-us/download/details.aspx?id=7684

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

Microsoft Exchange sensorThe Microsoft Exchange sensor discovers Microsoft Exchange servers.

For the supported versions of Microsoft Exchange servers, see Sensors and supported target systemsdocument.

Notes:

• In TADDM releases prior to TADDM 7.2.2, this sensor was named Microsoft Exchange 2007 Serversensor.

• The Microsoft Exchange sensor supports only script-based and asynchronous discovery. It does notsupport regular discoveries.

Sensor name that is used in the GUI and logsExchangeSensor

PrerequisitesThe sensor uses the Exchange Management Tools that are included with Microsoft Exchange Server 2007and Microsoft Exchange Server 2010.

If you are using Microsoft Exchange Server 2007 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


https://www.microsoft.com/en-us/download/details.aspx?id=7684

https://www.microsoft.com/en-us/download/details.aspx?id=7684


If you are using Microsoft Exchange Server 2010 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.E2010;Get-ExchangeServer

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

Model objects with associated attributesThe Microsoft Exchange sensor creates model objects with associated attributes. The attributes indicatethe type of information that the sensor collects about Microsoft Exchange Server resources in your ITenvironment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.app.messaging.exchange.AcceptedDomain

• AcceptedDomainName• Default• DistinguishedName• DomainName• DomainType• Parent

app.messaging.exchange.ActiveSyncVirtualDirectory

• BasicAuthenticationEnabled• ClientAccessServer• ClientCertEnabled• DistinguishedName• ExternalURL• InternalURL• Path• RemoteDocumentsActionForUnknownServers• VirtualDirectoryName• WebSiteName• WebSiteSSLEnabled

app.messaging.exchange.ClientAccess

• ClientAuthenticationMethod• ExchangeProtocols• ExternalHostName• Host• Name• OutlookAnywhereEnabled• PrimarySAP• ProductName• ProductVersion• RoleName


• SSLOffloading• VersionString

The ClientAuthenticationMethod, ExternalHostName, and SSLOffloading attributes apply only whenthe Outlook Anywhere feature is enabled.

app.messaging.exchange.EdgeTransport

• AcceptedDomains• AntiSpamUpdatesEnabled• ConnectivityLogEnabled• ConnectivityLogPath• DelayNotificationTimeout• ExternalDNSAdapterEnabled• Host• InternalDNSAdapterEnabled• MaxOutboundConnections• MaxPerDomainOutboundConnections• MessageExpirationTimeout• MessageTrackingLogEnabled• MessageTrackingLogPath• ObjectType• OutboundConnectionFailureRetryInterval• PrimarySAP• ProductName• ProductVersion• Queues• ReceiveConnectors• ReceiveProtocolLogPath• RoleName• SendConnectors• SendProtocolLogPath• TransientFailureRetryCount• TransientFailureRetryInterval• TransportRules• VersionString

app.messaging.exchange.HubTransport

• AntiSpamUpdatesEnabled• ConnectivityLogEnabled• ConnectivityLogPath• DelayNotificationTimeout• ExternalDNSAdapterEnabled• Host• InternalDNSAdapterEnabled• Journals• MaxOutboundConnections


• MaxPerDomainOutboundConnections• MessageClassifications• MessageExpirationTimeout• MessageTrackingLogEnabled• MessageTrackingLogPath• ObjectType• OutboundConnectionFailureRetryInterval• PrimarySAP• ProductName• ProductVersion• Queues• ReceiveConnectors• ReceiveProtocolLogPath• RoleName• SendConnectors• SendProtocolLogPath• TransientFailureRetryCount• TransientFailureRetryInterval• TransportRules• VersionString

app.messaging.exchange.TransportServer

• AntiSpamUpdatesEnabled• ConnectivityLogEnabled• ConnectivityLogPath• DelayNotificationTimeout• ExternalDNSAdapterEnabled• Host• InternalDNSAdapterEnabled• MaxOutboundConnections• MaxPerDomainOutboundConnections• MessageExpirationTimeout• MessageTrackingLogEnabled• MessageTrackingLogPath• ObjectType• OutboundConnectionFailureRetryInterval• PrimarySAP• ProductName• ProductVersion• Queues• ReceiveConnectors• ReceiveProtocolLogPath• RoleName• SendConnectors


• SendProtocolLogPath• TransientFailureRetryCount• TransientFailureRetryInterval• TransportRules• VersionString

app.messaging.exchange.ExchangeConnector

• Enabled• Fqdn• ProtocolLoggingLevel

This class is extended by the ReceiveConnector and SendConnector which are direct subclasses ofthis class.

app.messaging.exchange.ExchangeJournalRule

• EmailAddress• JournalRuleIdentity• Parent• Recipient• Scope

app.messaging.exchange.ExchangeMailbox

• ActiveDirectoryGUID• Alias• Enabled• LegacyDN• MailboxDisplayName• OrganizationalUnit• Parent• PrimarySmtpAddress• RecipientTypeDetails• UserDistinguishedName

app.messaging.exchange.ExchangeMailboxStore

• AllowFileRestore• CopyEdbFilePath• DatabaseName• DatabasePath• DeletedItemRetention• DistinguishedName• IssueWarningQuota• JournalRecipient• LastFullBackup• LastIncrementalBackup• MailboxRetention• MailboxStoreName• Mailboxes


• MaintenanceSchedules• MountAtStartup• ProhibitSendQuota• ProhibitSendReceiveQuota• PublicFolderStore• QuotaNotificationSchedules• RetainDeletedItemsUntilBackup

app.messaging.exchange.ExchangeProtocol

• AuthenticatedConnectionTimeout• Banner• DistinguishedName• LoginType• MaxCommandSize• MaxConnections• MaxConnectionsFromSingleIP• MaxConnectionsPerUser• PreAuthenticatedConnectionTimeout• ProtocolName• ProxyTargetPort• SSLBindings• UnencryptedOrTLSBindings• X509CertificateName

app.messaging.exchange.ExchangePublicFolder

• AgeLimit• Children• DeletedItemLifetime• MailEnabled• MaximumItemSize• Parent• Path• PerUserReadDisabled• ProhibitPostLimit• PublicFolderName• ReplicaAgeLimit• URL• UseDatabaseQuotaDefaults• UseDatabaseReplicationSchedule• UsePublicStoreAgeLimits• UsePublicStoreDeletedLifetime• WarningLimit

app.messaging.exchange.ExchangePublicFolderStore

• AllowFileRestore• CopyEdbFilePath


• CustomReferralServerList• DatabaseName• DatabasePath• DeletedItemRetention• DistinguishedName• IssueWarningQuota• ItemRetentionPeriod• LastFullBackup• LastIncrementalBackup• MaintenanceSchedules• MaxItemSize• MountAtStartup• ProhibitPostQuota• PublicFolderHierarchy• PublicFolderStoreName• PublicFolders• QuotaNotificationSchedules• ReplicationMessageSize• ReplicationPeriod• ReplicationSchedules• RetainDeletedItemsUntilBackup• StorageGroup• UseCustomReferralList

app.messaging.exchange.ExchangeServer

• Accepteddomain• ActiveDirectoryDomainName• ActiveDirectoryGUID• AdministrativeGroup• CreationTime• DistinguishedName• Domain• Edition• ErrorReportingEnabled• ExchangeArchitecture• ExchangeGroup• Host• Journals• MessageClassifications• Name• ObjectType• PrimarySAP• ProductID• ProductName


• ProductVersion• Protocols• ServerRoles• Site• VendorName• VersionString• VirtualDirectories

app.messaging.exchange.ExchangeServerRole

• Name• ProductName• ProductVersion• RoleName• VersionString

This class is extended by the ClientAccess, TransportServer (EdgeTransport and HubTransport), andUnifiedMessagingServer which are direct subclasses of this class.

app.messaging.exchange.ExchangeVirtualDirectory

• ClientAccessServer• DistinguishedName• ExternalURL• InternalURL• Path• VirtualDirectoryName

This class is extended by the ActiveSyncVirtualDirectory, OABVirtualDirectory, andOwaVirtualDirectory which are direct subclasses of this class.

app.messaging.exchange.MailboxServer

• AutoDatabaseMountDial• ClusteredStorageType• ForcedDatabaseMountAfter• Host• Name• PrimarySAP• ProductName• ProductVersion• RedundantMachines• RoleName• StorageGroups• VersionString• VirtualDirectories

app.messaging.exchange.OABVirtualDirectory

• PollInterval• VirtualDirectoryName

This class extends the ExchangeVirtualDirectory class.


app.messaging.exchange.OwaVirtualDirectory

• ActiveSyncIntegrationEnabled• AllAddressListsEnabled• BasicAuthentication• CalendarEnabled• ChangePasswordEnabled• ContactsEnabled• DefaultDomain• Description• DigestAuthentication• FormsAuthentication• JournalEnabled• JunkEmailEnabled• LogonFormat• MailboxServer• NotesEnabled• OwaVersion• PremiumClientEnabled• PublicFoldersEnabled• RecoverDeletedItemsEnabled• RemindersAndNotificationsEnabled• RulesEnabled• SMimeEnabled• SearchFolderEnabled• SignatureEnabled• SpellCheckerEnabled• TasksEnabled• ThemeSelectionEnabled• UMIntegrationEnabled• VirtualDirectoryName• WebSiteName• WindowsAuthentication

app.messaging.exchange.ReceiveConnector

• AnonymousUsersPermission• BasicAuthRequiresTLS• BasicAuthentication• BindAddresses• ConnectorName• DistinguishedName• Enabled• ExchangeAuthentication• ExchangeLegacyServersPermission• ExchangeServersPermission


• ExchangeUsersPermission• ExternalAuthoritative• Fqdn• MaxMessageSize• MutualAuthTLS• PartnersPermission• ProtocolLoggingLevel• RemoteIPRanges• TLS• WindowsAuthentication

app.messaging.exchange.SendConnector

• AddressSpaces• ConnectorName• DistinguishedName• DNSRoutingEnabled• DomainSecureEnabled• Enabled• Fqdn• IsScoped• MaxMessageSize• ProtocolLoggingLevel• SmartHosts• UseExternalDNSRoutersEnabled

app.messaging.exchange.TransportRule

• Comments• Enabled• Parent• RulePriority• TransportRuleName

app.messaging.exchange.UMDialPlan

• DigitsInExtension• DistinguishedName• UMDialPlanName

app.messaging.exchange.UnifiedMessagingServer

• Host• Languages• MaxCallsAllowed• MaxFaxCallsAllowed• ProductName• ProductVersion• RoleName• StorageGroups


• UMDialPlans• VersionString



The sensor requires the credentials (user name and password) for the computer system on which theExchange Server is running ComputerSystem (Windows).


1. Select ComputerSystem (Windows) as the Component Type.2. Specify the access information (user name and password) that TADDM must use to access the Active

Directory domain on which the Exchange Server is running. The user must be a member of the localadministrators group, and must be assigned Exchange View Only Administrator permissions on theExchange Server 2007.

3. Specify the access information (user name and password) that TADDM must use to access the EdgeTransport server role. The Edge Transport server role is hosted on a dedicated computer and requiresseparate access information.

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

com.collation.discover.agent.ExchangeServerAgent.capturePublicFolders=trueThe default value is true, which means that the sensor discovers Microsoft Exchange public folders.

This property specifies whether public folders are discovered and stored in the TADDM database.Depending upon the size of the environment and the number of folders that need to be discovered,you can change the default value to improve performance. If you set the value to false a deepdiscovery of the public folders is not performed.

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

The Exchange sensor does not startProblem

The Exchange sensor is not started.Solution

For Microsoft Exchange Server 2007, ensure that the following services are started:

• Microsoft Exchange Information Store (store.exe)• Microsoft Exchange Service Host (Microsoft.Exchange.ServiceHost.exe)• Microsoft Exchange Transport (MSExchangeTransport.exe)• Microsoft Exchange Unified Messaging (umservice.exe)

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


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

The Exchange sensor completes successfully with the following message: Stored-0 ExchangeServer in the database.

SolutionNo active Exchange Server is running on the target computer system. The possible causes for noExchange Server running are:

• The Exchange Server is installed as a cluster node, but it is currently inactive. For MicrosoftExchange Server 2007, start the cluster administration program on the computer where theExchange Server is installed as a cluster node. Then verify that the node is active.

• The Server is acting as a provisioning volume and is not hosting any of the server roles.• Check the log file for the cause of the failure and verify that the gateway is configured correctly.

Invalid domain credentials usedProblem

The sensor ends with the following error message:

CTJTD0835E Invalid domain credentials.

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

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

Note: In TADDM releases prior to TADDM 7.2.2, this sensor was named Microsoft Exchange Server sensor.

Sensor name that is used in the GUI and logsExchange2003Sensor

PrerequisitesThe account TADDM uses to access the windows gateway must have an Active Directory account and nota local account on the gateway.

LimitationsNote the following limitations:

• In an Exchange Server clustering environment, the sensor discovers only the active cluster node.• The sensor discovers the virtual servers for only the SMTP and X400 protocols.


• app.messaging.exchange.ExchangeAdministrativeGroup• app.messaging.exchange.ExchangeConnector• app.messaging.exchange.ExchangeDSAccessDomainController• app.messaging.exchange.ExchangeFolderTree• app.messaging.exchange.ExchangeLink


• app.messaging.exchange.ExchangeMailbox• app.messaging.exchange.ExchangeMailboxStore• app.messaging.exchange.ExchangeProtocolVirtualServer• app.messaging.exchange.ExchangePublicFolder• app.messaging.exchange.ExchangePublicFolderStore• app.messaging.exchange.ExchangeQueue• app.messaging.exchange.ExchangeRoutingGroup• app.messaging.exchange.ExchangeScheduleInterval• app.messaging.exchange.ExchangeServer• app.messaging.exchange.ExchangeStorageGroup

Configuring the sensorBefore running a discovery, you must configure the Microsoft Exchange server 2003 that you want theTADDM server to discover.

The Microsoft Exchange Management service must be running on the target Windows system beforerunning a discovery. The Windows service ID for the TADDM service account must be created on theWindows system on which the Microsoft Exchange server is running. The Windows service ID musthave full permission (Execute Methods, Full Write, Partial Write, Provider Write, Enable Account,Remote Enable, Read Security, and Edit Security) to the following WMI namespaces:

• Root\CIMV2• Root\CIMV2\Applications\Exchange• Root\MicrosoftExchangeV2

If the Windows service ID for the TADDM service account has sufficient permissions to discover aMicrosoft Exchange server, the sensor uses the Windows service ID and a separate MicrosoftExchange server access list entry is not required.

If the Windows service ID for the TADDM service account does not have sufficient permissions todiscover a Microsoft Exchange server, you must create a separate Microsoft Exchange server accesslist.



1. Select Messaging servers as the Component Type.2. Select Microsoft Exchange Server for the Vendor.3. Specify the following required information:

a. User nameb. Password

The sensor uses credentials from the access list in the following sequence:

1. The sensor attempts to connect to the Microsoft Exchange Server, using Microsoft Exchange Serveruser credentials from the access list.

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



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

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

This property specifies the timeout (in milliseconds) for the WMI call to get the Exchange Serverinformation.

If the WMI call takes a long time (which might occur in large environments), you can increase thisvalue.

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

Sensor is not startedProblem

The Exchange 2003 sensor is not started.Solution

For Microsoft Exchange Server 2003, ensure that the Microsoft Exchange Management service isstarted on the target Windows system. Run the services.msc program to check the status of theservice.

Discovery does not find any systemsProblem

The Exchange 2003 sensor completes successfully with the following message: “There was nothing tobe discovered.”

SolutionNo active Exchange Server is running on the target computer system. The following lists the possiblecauses:

• The Exchange Management Tool is installed, but the Exchange Server is not installed. For MicrosoftExchange Server 2003, ensure the following things are done:

1. Start the Exchange System Manager on the computer where the Exchange Server is installed.2. In the list of servers, verify that the local Exchange Server is displayed.3. If the local Exchange Server is not displayed, verify that the Microsoft Exchange Server is

installed and running correctly.• 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 installedas a cluster node.

2. Check which Exchange resource is assigned to the Exchange virtual server.

Sensor cannot retrieve server informationProblem

The Exchange 2003 sensor terminates with the following error message:

CTDTD0811E The Exchange Server Agent is unable to retrieve information from the Microsoft Exchange Server


SolutionThis error message means that no output was retrieved through the Windows ManagementInstrumentation (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 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 discoveredProblem

The Exchange 2003 sensor terminates with the following error message: CTDTD0812E No MicrosoftExchange Server is found.

SolutionThis error message means that no Exchange Server object exists in the output that was retrievedthrough the Windows Management Instrumentation (WMI). For Microsoft Exchange Server 2003,complete the following steps:

1. Run the services.msc program on the target Windows system.2. Restart the Microsoft Exchange Management service.3. Run the discovery again.4. If the problem still persists, see the sensors/ ExchangeServerSensor-*.log file to

determine if the problem is WMI related.

Sensor cannot access Windows Management Instrumentation (WMI) namespaceProblem

The following message is in the sensors/ExchangeServerSensor-*.log file:

System.UnauthorizedAccessException: Access denied

SolutionThe message typically means that the TADDM service account does not have the appropriatepermission to access the required WMI namespace. For Microsoft Exchange Server 2003, completethe following steps:

1. Ensure that the TADDM service account has full permission for the following WMI namespaces:

Root\CIMV2Root\CIMV2\Applications\ExchangeRoot\MicrosoftExchangeV2

To configure the permission, complete the following steps:

a. Click Start > Run > Open wmimgmt.msc.b. Right-click WMI Control (Local), and click Properties.c. In the WMI Control (Local) Properties window, click the Security tab.d. Click WMI namespace, and click Security.e. In the Security window, select the following permissions to allow the user or group:

• Execute Methods• Full Write• Partial Write• Provider Write• Enable Account


• Remote Enable• Read Security• Edit Security

2. Ensure that the TADDM service account has enough permission for the Exchange Server and FolderTree objects. To configure the permission, complete the following steps:

a. ClickStart > All Programs > Microsoft Exchange > System Manager

b. In the Exchange System Manager, expand Servers tree and find the server object to bediscovered.

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:

• Read• Execute• Read permissions• List contents• Read properties• List object• View information store status

g. In the Exchange System Manager, expand Folders tree and find the folder tree object to bediscovered.

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

WMI class does not existProblem

The following message appears in the sensors/ ExchangeServerSensor-*.log file:

System.Management. ManagementException: Invalid class

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

Unexpected discovery resultProblem

The virtual servers for the following protocols are not discovered:

• HTTP• IMAP4• NNTP• POP3


SolutionFor Microsoft Exchange Server 2003, the sensor supports virtual servers for only SMTP and X400protocols.

Microsoft HyperV sensorThe Microsoft HyperV sensor discovers Microsoft Windows based computer systems with the Hyper-Vserver. The discovery includes the host (also known as parent or root partition) and the virtualized guestcomputer systems (also known as child partitions) in a Hyper-V environment.

Sensor name that is used in the GUI and logsMicrosoft HyperV Sensor

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

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

Model objects with associated attributesThe Microsoft HyperV sensor creates model objects with associated attributes. The attributes indicate thetype of information that the sensor collects about Microsoft Windows based computer systems withMicrosoft Hyper-V server in your IT environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.sys.ComputerSystem

The following attribute is associated with the host running the Hyper-V software:

• ChildSystem (host)

sys.ComputerSystemThe following attributes are associated with the discovered objects that are virtualized on the host:

• HostSystem• IsVMIDanLPAR• Manufacturer• MemorySize• Model• Name• NumCPUs• SerialNumber• UUID• Virtual• VirtualMachineState

app.AppServer

• Host• MajorVersion


• ProductName• ProductVersion• VendorName• VersionString


The Microsoft HyperV sensor uses the same Computer System (Windows) access credentials that arerequired to discover the target host (parent partition). No additional configuration is necessary.

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

Guest computer systems are not displayedProblem

The HyperV sensor ran, but where are the guests located in the Data Management Portal after adiscovery?

Solution

In the Discovered Components pane go to Inventory Summary > Computer Systems > OtherComputer Systems, to find the Hyper-V guest systems (child partitions).

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

IIsWebServiceSensor supports discovery of IIS 6.0, IISServerSensor supports discovery of IIS 7.0, andlater.

Restriction: The Microsoft IIS Web server sensor no longer sets the IIsParametersRow attribute for theIIsWebServer, IIsWebService, and IIsWebVirtualDir classes. Use the IIsParameters attribute instead.

IISServerSensor discovers connection strings, which are then stored in the XML format in the XD attributeof the IISModule class. Basing on these connection strings, topology agents create dependenciesbetween IIS module and the Oracle databases that the module uses.

The Microsoft IIS Web server sensor discovers the tnsnames.ora file, which is used for settingconnection strings information when the Oracle database is used. The sensor discovers the file on thetarget system in the following locations in the specified order:

1. The <path entry>\..\network\admin\ directory for each path entry that is specified in the%PATH% variable.

2. The location that is specified by the com.ibm.cdb.tnsNamesLocation property.3. The Oracle client installation directory that is specified in the %PATH% variable.4. %TNSNAMES_PATH%\tnsnames.ora.5. %ORACLE_HOME%\network\admin\tnsnames.ora.

In TADDM 7.3.0.4, and later, TADDM supports non-admin discovery of IIS servers. For details,see “Configuring for a non-admin IIS discovery” on page 116.

Sensor name that is used in the GUI and logsIIsWebServiceSensor, IISServerSensor


PrerequisitesEnsure that the following requirements are met.Requirements for discovery of all versions of IIS

• Discovery of the computer system must succeed.

Requirements for discovery of IIS 6.0

Note: The operating systems on which IIS 6.0 targets are running were withdrawn from support.Therefore, as the sensor has been maintained and updated to discover new releases of the targets,the IIS 6.0 discovery may fail.

• The gateway must have the IIS Manager installed. This method ensures that the COM classes areinstalled. These classes are required by the TaddmTool AdsiDump and AdsiEnum commands

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

.Requirements for discovery of IIS 7.0, and later

To discover IIS 7.0 servers, the IIS PowerShell Snap-In must be installed on the target server. The IISPowerShell Snap-In is included in IIS Management Scripts and Tools. You can also download it withthe appropriate package from Microsoft Download Center and install it manually.


• app.ProcessPool• app.web.iis.IIsModule• app.web.iis.IIsParameter• app.web.iis.IIsWebServer• app.web.iis.IIsWebService• app.web.iis.IIsWebVirtualDir• sys.RuntimeProcess

• app.web.iis.IIsAppPool

Note:

1. The modules that are discovered by the sensor are of the IIsWebVirtualDir class. The sensor does notdiscover IIS modules and the IIsModule class is not used for IIS modules.

2. The app.web.iis.IIsAppPool model object is created only by the IISServerSensor.

Configuring the sensorBefore running a discovery, you must configure the Microsoft IIS Web server sensor.


There are no specific access requirements. This sensor can be run using the ComputerSystem accesscredentials used to discover the client.


Configuring the discovery profileYou can customize the setting for the Microsoft IIS Web server sensor by configuring the sensorconfiguration in Discovery Management Console.

If you want to customize the IIsWebServiceSensor, and IISServerSensor, create a new discovery profile inDiscovery Management Console. In that profile, create a new sensor configuration, and select the Enablethis configuration and disable selected configuration check box.

You can modify the following discovery profile properties:

discoverIISParametersThis property specifies whether IIS Parameters are discovered. By default, the property is set totrue, which means that the parameters are discovered.The IIS parameters might be large and might cause performance degradation, or out of memoryerrors. If you do not want to discover these parameters, set this property to false.

tagsToMaskThis property specifies a comma-separated list of properties in connection strings. Any text content ofthese properties in connection strings that are discovered is masked with asterisks.The default value of this property is password,pwd.

Note: This property is available only for IISServerSensor.

Configuring for a non-admin IIS discoveryYou can configure the Microsoft IIS Web server sensor to run non-admin discovery of IIS servers. Suchdiscovery does not require a user with administrator rights. In this mode, the User Account Control (UAC)option can be enabled.

Note: Non-admin discovery is supported only with IISServerSensor, which supports IIS 7.0, and later.

With non-admin discovery, the User Account Control (UAC) option can be enabled. Depending on whetheryou use WMI or PowerShell session, you can create the following types of users:

• For WMI session, users that are not administrators but belong to the administrators group aresupported.

• For PowerShell session, users that are not administrators and do not belong to the administrators groupare supported.

ProcedureTo configure TADDM to run non-admin discovery of IIS servers, complete the following steps:

1. Copy the following files to the target system:

• From the $COLLATION_HOME/dist/support/bin directory:

– copyFiles.ps1– dcomConfiguration.ps1– iisConfiguration.ps1– nonadmin.properties– psSessionConfiguration.ps1– scriptsRunner.bat– scriptsRunner.ps1– wmiConfiguration.ps1– wrmConfiguration.ps1

• From the $COLLATION_HOME/dist/lib/ms/gateway directory:

– TaddmWmi.pdb– TaddmWmi.exe– TaddmWmi.mof


– TaddmWmi.dll2. Configure the nonadmin.properties file by updating the nonadmin.user, andnonadmin.files.path properties:

nonadmin.user=usernonadmin.wmi.namespace=rootnonadmin.files.path=pathnonadmin.permissions=Enable,MethodExecute,RemoteAccessnonadmin.components.iis7=yes

The user value is the user that you want to use for non-admin discovery. If you specify the localuser, you need to add only the user name. Otherwise, provide also the domain name, for example,domain\user. The path value is the path to the directory where you copied files in step 1. Do notmodify the values of the remaining properties.

3. Run the scriptsRunner.bat file as administrator with one of the following options:

• scriptsRunner.bat set -wmi - sets permissions for WMI session.• scriptsRunner.bat set -ps - sets permissions for PowerShell session.• scriptsRunner.bat set -wmi -ps - sets permissions for both WMI and PowerShell

sessions.

If you decide not to run non-admin discoveries any longer, you can revert to the original configuration. Runthe scriptsRunner.bat with one of the following options:

• scriptsRunner.bat revert -wmi• scriptsRunner.bat revert -ps• scriptsRunner.bat revert -wmi -ps

Related tasks“Configuring for a non-admin Windows discovery” on page 360You can configure the sensor to run discoveries without providing user credentials with the administratorrole.

Differences between IISServerSensor and IIsWebServiceSensorIISServerSensor and IisWebServiceSensor discover various versions of IIS. When they are combined inone discovery profile, all versions of IIS that are supported by TADDM can be discovered by using thisprofile.

IISServerSensorIISServerSensor is a separate sensor that supports discovery of IIS 7 and later by using PowerShellIIS Snap-in cmdlets. This sensor supports only script-based or asynchronous discovery. It uses newnaming of IIS metabase properties and configuration settings. Changed attributes are stored in theexisting model.

IIsWebServiceSensorIIsWebServiceSensor is an earlier sensor that supports discovery of IIS 6.0 or earlier. It runs regulardiscovery by using the TaddmTool AdsiDump and AdsiEnum commands.

Note: For all non-default profiles, which have IIsWebServiceSensor enabled, IIsWebServiceSensor isalso enabled after the migration.

Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft IIS Web server sensor and presentssolutions for those problems.

IIS module dependencies are not included in business applications


ProblemEven when IIS module dependencies are created, they are not included in business applications.

SolutionThe IIS module dependencies are not included in business applications because the default groupingpattern configuration excludes such relations. To solve the issue, complete the following steps:

1. Export the default configuration by running the bizappscli tool:

$COLLATION_HOME/sdk/bin/bizappscli.sh exportDefaultConfiguration -f conf.xml

2. Open the conf.xml file and remove the following lines:

<exclude relation="{any}" source="app.web.iis.IIsModule" target="{any}"/><exclude relation="{any}" source="{any}" target="app.web.iis.IIsModule"/>

3. Import the modified configuration by running the bizappscli tool:

$COLLATION_HOME/sdk/bin/bizappscli.sh importDefaultConfiguration -f conf.xml

No Web server information discoveredProblem

The sensor does not discover any Web server information.Solution

If the Web server information is missing, check the logs to determine if the TaddmTool programAdsiDump and AdsiEnum commands succeeded or failed.Check whether the TaddmTool program QueryRegistry commands succeeded. Two registry pathsare queried.

• HKLM\SOFTWARE\Microsoft\W3SVC• HKLM\SYSTEM\CurrentControlSet\Services\W3SVC

The first key provides general software information for IIS and the second provides service-relatedinformation.

Web server is duplicatedProblem

During discovery, duplicate IIS Web servers are found. This problem can occur when the IIS Webservers have been discovered with an earlier version of TADDM. Earlier releases of TADDM used port 0as the default listening port. If the same servers are discovered using a different listening port, theseservers are duplicated and they cannot be automatically merged.

SolutionUse an SQL statement to identify duplicate IIS Web servers in the database. The following statementcan be run on one line, on DB2 or Oracle databases:

select cast(APPZ.contextip_x as VARCHAR(100)) as CONTEXT_IP, APPZ.guid_x as OLD_GUID, APPZ.displayname_x as OLD_DISPLAYNAME, APPN.guid_x as NEW_GUID, APPN.displayname_x as NEW_DISPLAYNAME from APPSRVR APPZ INNER JOIN APPSRVR APPN ON APPZ.contextip_x = APPN.contextip_x AND APPZ.jdoclassx = APPN.jdoclassxwhere APPZ.jdoclassx='com.collation.topomgr.jdo.topology.app.web.iis.IIsWebServiceJdo' and APPZ.displayname_x like '%:0' and APPN.displayname_x not like '%:0'

Use one of the following methods to remove the duplicates:


• Merge the duplicates in the Data Management Portal.• Manually delete the old configuration items.

For more information about merging and deleting discovered configuration items, see the Discoverytasks topic in the TADDM User's Guide.

System fails with an unknown error (0x80005000)Problem

While discovering IIS8 on the Windows Server 2012 with User Account Control turned on, thefollowing error occurs:

System.Runtime.InteropServices.COMException (0x80005000): Unknown error (0x80005000)

SolutionTo fix the problem, complete the following steps:

1. On the target machine, run the Registry Editor, Regedit.exe.2. Set the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System LocalAccountTokenFilterPolicy value to 1.

3. In the Control Panel window, click the Administrative Tools tab and open Local Security Policy.4. Expand Local Policies and click Security Options.5. Change the following policies:

• Set the Behavior of the elevation prompt for administrators in Admin Approval Mode policy toElevate without Prompting.

• Set the User Account Control: Detect application installations and prompt for elevation policyto Disabled.

In order to configure policies on the system with Active Directory, complete the following steps:

1. In the Control Panel window, click the Administrative Tools tab and open Group PolicyManagement.

2. Choose forest and domain and select Default Domain Policy.3. Click Action > Edit.4. Open Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security options.

5. Change the following policies:



After you upgrade to 7.3, out of memory errors occur when you run the Microsoft IISWeb server sensorProblem

When you run the discovery by using the Microsoft IIS Web server sensor after you upgraded toTADDM 7.3, out of memory errors occur.

SolutionIf in TADDM 7.2.2 you set the com.collation.discover.agent.IIsWebServiceAgent.discoverIISParameters property to false in the collation.properties file, this is the causeof the problem. In TADDM 7.3, this property is no longer in the collation.properties file.Therefore, after the upgrade, its value is set to true.


To modify its value, open the sensor configuration in Discovery Management Portal, and search for thediscoverIISParameters. Set the value to false.

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

Sensor name that is used in the GUI and logsNFSServerSensor


• sys.NFSExport• sys.NFSSAP• sys.NFSService• sys.ServiceAccessPoint

Pacemaker Cluster sensorThe Pacemaker Cluster sensor discovers a Pacemaker Cluster. The sensor discovers the nodes, resources,resource groups, resource clones, multi-state resources, their meta attributes, resource attributes, clusterproperties on the cluster. This sensor script-based and also supports asynchronous discovery.

Sensor name that is used in the GUI and logsPacemakerClusterSensor

PrerequisitesThe Pacemaker Cluster sensor requires:

• The successful discovery of Linux computer systems• The cluster must be in started mode on the node used as a discovery target.• The nodes used as a target can be either a Cluster Node or Remote Node.• pcs command is available to be run on the cluster node to fetch information about the cluster.• Cluster name must be unique in the customer environment as it is used as a Naming Rule attribute and

is used to uniquely identify a Pacemaker Cluster.• The Sensor uses the IP addresses of the node names of the Cluster to link the discovered nodes of the

cluster with the respective computer systems. The IP addresses of the Computer System which are partof the pacemaker cluster must be unique in the customer environment.

• The IP address of the node names of the cluster is determined either by using the nslookup commandon node name or by looking the node names in /etc/hosts file on the target. Either one of thesemechanisms must be available to translate node names to IP addresses.

Security issuesA Computer System user is used to discover the Pacemaker Cluster.

This discovery user must have privileges to execute the pcs command and access the cluster informationin at least read-only mode.

On Red Hat Enterprise Linux 7, the following steps specify how to give read-only permission to a localuser, for more details refer https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-accesscontrol-haar.


https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-accesscontrol-haar

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-accesscontrol-haar

1. Add discovery user to the haclient group by running the following command:

usermod -a -G <discoveryUser>2. Enable Pacemaker ACLs by setting the enable-acl cluster property:

pcs property set enable-acl=true --force3. Create a role with read-only permissions for the cib:

pcs acl role create <ROLE-NAME> description="Readonly access to cluster"read xpath /cib

4. Create the user <discoveryUser> in the pcs ACL system and assign that user the read-only role:

pcs acl user create <discoveryUser> <ROLE-NAME>

Limitations1. The scope of discovery must contain the IP address of at least one of the Pacemaker Cluster nodes. A

node is any computer that is part of the cluster.2. Guest nodes may not be discovered.3. Resource operations, Location/Ordering/Colocation/Ticket constraints, Stonith, Fencing, Quorum,

Alerts and Multi-Site Cluster using a Booth cluster ticket manager will not be discovered.

Model objectsThe Pacemaker Cluster sensor creates model objects.

The Pacemaker Cluster sensor creates the following model objects:

• app.pacemaker.PacemakerCluster• app.pacemaker.PacemakerNode• app.pacemaker.PacemakerClusterNode• app.pacemaker.PacemakerRemoteNode• app.pacemaker.PacemakerResourceGroup• app.pacemaker.PacemakerResource• app.pacemaker.PacemakerResourceClone• app.pacemaker.PacemakerMultiStateResource• app.pacemaker.PacemakerClusterProperty• app.pacemaker.PacemakerResourceDefaultMetaAttribute• app.pacemaker.PacemakerNodeProperty• app.pacemaker.PacemakerGroupedResource• app.pacemaker.PacemakerResourceAttribute• app.pacemaker.PacemakerResourceMetaAttribute• app.pacemaker.PacemakerCloneMetaAttribute• app.pacemaker.PacemakerMultiStateMetaAttribute



1. This sensor is script-based and uses the same ComputerSystem type discovery user that is used forLinuxComputerSystemSensor.


2. The discovery user needs to have permission to run the cluster commands as mentioned in the the'Pacemaker Cluster sensor' in the Administering Guide.


The sensor uses the following entries in the collation.properties file:com.ibm.cdb.topomgr.topobuilder.agents.PacemakerClusterAgent.setComputerSystemPacemakerClusterRel=false

This property specifies whether Pacemaker Cluster Topology Builder Agent sets the relationshipbetween ComputerSystem and PacemakerCluster. If this property is set to true, the relationshipis set.The default value is false.

Oracle Application Server sensorThe Oracle Application Server sensor discovers Oracle Application Server servers.

Sensor name that is used in the GUI and logsOracleAppSensor and OracleAppOpmnSensor

PrerequisitesNote the following prerequisites:

• Discovery of the computer system must succeed.• An Oracle Application Server account must be entered in the access list.• An account with admin privilege is required (read-only ID can work).• Oracle Application Server libraries must be made available on the TADDM server.• Relative paths are relative to $COLLATION_HOME.• Requires two subdirectories:

– j2ee– opmn

These files can be copied or NFS mounted from an existing Oracle Application Server installation.

The required JAR files on the TADDM server are:

– j2ee/home/lib/ejb.jar– j2ee/home/lib/adminclient.jar– j2ee/home/lib/javax77.jar– j2ee/home/lib/jmxcluster.jar– j2ee/home/lib/jmx_remote_api.jar– j2ee/home/lib/jmxri.jar– j2ee/home/oc4jclient.jar– opmn/lib/argus.jar– opmn/lib/ons.jar– opmn/lib/opmnconfig.jar– opmn/lib/optic.jar– opmn/lib/repositorycheck.jar

• Specify the location of the files in the com.collation.oracleapp.root.dir entry in thecollation.properties file.


• These files must have read privileges for the collation user.

Model objects createdThe OracleAppAgent creates the following model objects:

• app.AppConfig• app.ConfigFile.SoftwareContainer• app.j2ee.EJB• app.j2ee.EntityBean• app.j2ee.J2EEComponent• app.j2ee.J2EEDeployedObject• app.j2ee.J2EEModule• app.j2ee.J2EEResource• app.j2ee.JSP• 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• app.j2ee.oracleapp.OracleAppWebModule• app.j2ee.StatefulSessionBean• app.j2ee.StatelessSessionBean• core.LogicalContent• enums.StatusEnum• net.BindAddress• net.IpAddress• sys.ComputerSystem

The OracleAppOpmn creates the following model objects:

• app.AppConfig• app.ConfigFile• app.j2ee.oracleapp.OracleAppCluster


• app.j2ee.oracleapp.OracleAppProcessManager• app.web.oracleapp.OracleAppHTTPServer• core.LogicalContent• enums.StatusEnum• net.BindAddress• net.IpAddress• sys.ComputerSystem



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


com.collation.oracleapp.root.dir=lib/oracleappThe default value is lib/oracleapp.

This property specifies the location of the Oracle Application Server libraries on the TADDM server.

You can specify an absolute or relative path for the directory location. If the value for this property is arelative path directory, the relative path is appended to the $COLLATION_HOME path.

com.collation.platform.os.ignoreLoopbackProcesses=trueThe default value is true, which means that the processes that are listening on loopback interfacesare ignored. Therefore, if a server is listening only on the loopback IP address (127.0.0.1), and not onany 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 fordiscovery.

You must set this property to true if you want to discover an Oracle Application Server or theWebLogic sensors. For example, if the WeblogicServerVersionSensor sensor tries to start using a localhost address, this property must be set to true.

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


The lsof program is not properly set up to return information about all processes.Solution

Ensure that you discover a supported version of Oracle Application Server.

The Oracle Application Sensor runs the opmnctl status command. Verify that the system user thatis used for discovery has privileges to run this command.

The following list describes other possible reasons why the sensor does not start:

• The LiSt Open Files (lsof) program is not correctly set up to return information about all processes.One of the following requirements for running the lsof program must be met:


– The setuid (set user ID) access right flag must be set for the lsof program file.– The user must use the sudo command to run the lsof program.

• The value of the com.collation.platform.os.ignoreLoopbackProcesses property in the$COLLATION_HOME/etc/collation.properties file is set to false. The value must be set totrue for the sensor to start. A value of true specifies that the processes that are listening onloopback interfaces are to be ignored.

• The Oracle Application Server libraries are not available on the TADDM server. Oracle ApplicationServer libraries must be made available on the TADDM server. Use the following property to specifythe 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 relativedirectory, 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 therequired jar files:

– j2ee/home/lib/ejb.jar– j2ee/home/lib/adminclient.jar– j2ee/home/lib/javax77.jar– j2ee/home/lib/jmxcluster.jar– j2ee/home/lib/jmx_remote_api.jar– j2ee/home/lib/jmxri.jar– j2ee/home/oc4jclient.jar– opmn/lib/argus.jar– opmn/lib/ons.jar– opmn/lib/opmnconfig.jar– opmn/lib/optic.jar– opmn/lib/repositorycheck.jar

The Oracle Application Server sensor failsProblem

Oracle Application Server discovery is not supported on all platforms.Solution

Ensure that TADDM supports discovery of the Oracle Application Server on your operating system.

Sensor fails in remote serverProblem

The sensor fails in the remote server with an Agent terminated after exceeding timelimitnull error.

TADDM cannot find the Oracle Application Server libraries.

SolutionCheck the setting of the com.collation.oracleapp.root.dir property.


Sensor fails when trying to run discoverOpmnctl() methodProblem

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

SolutionAdd the bin directory of the Oracle Application Server to the path of the TADDM service account onthe Oracle Application Server system.

Sensor fails in remote server with Name not found error message in log fileProblem

The sensor fails and the following error is displayed in the log file:javax.naming.NameNotFoundException: oc4j:internal/ResourceFinder not found

SolutionAdd the IP address and host name of the Oracle Application Server to the /etc/hosts file on theTADDM server.

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

Sensor name that is used in the GUI and logsCCMSServerSensor

PrerequisitesThe SAP CCMS server sensor requires JCo libraries to function. For information about JCo libraries, see“Installing the SAP Java Connector (JCo) libraries” on page 126.

Depending on the specific application of SAP NetWeaver systems, you can use the SAP CCMS serversensor, the SAP SLD server sensor, or both to discover this system. SAP applications are installed on twodifferent database schemas depending on the application, and each are accessed by their respectiveruntime environments. There is a runtime environment for Java instances (Java stack) and one for theAdvanced Business Application Programming (ABAP) instances (ABAP stack):

• Use the SAP CCMS server sensor to discover information where the SAP NetWeaver system hasapplications based only on the ABAP stack.

• Use the SAP SLD server sensor to discover information where the SAP NetWeaver system hasapplications based only on the Java stack.

• Use the SAP CCMS server sensor, the SAP SLD server, or both sensors to discover information where theSAP NetWeaver system has applications based on both the ABAP and Java stacks.


Installing the SAP Java Connector (JCo) librariesYou must install the SAP Java Connector (JCo) 2.x libraries for the specific operating systems of theTADDM servers and/or anchors in the TADDM environment.

To install the JCo library files, complete the following steps, where operating_system represents AIX,Linux, Linuxs390x, or Windows:

1. Choose the appropriate SAP JCo libraries that are shipped with TADDM. The only version shipped withTADDM is 2.1 32bit.


The following table lists the typical name format of the SAP JCo library packages, listed by operatingsystem.

Table 13. Package names of the SAP JCo 2.x library files

Operating system Package name

AIX (32-bit) sapjco21P_10-10002239.zip

AIX (64-bit) sapjco21P_10-10002882.zip

Windows Server on x86_32 (32-bit) sapjco21P_10-10002243.zip

Windows on x86_64(64-bit) sapjco21P_10-20001730.zip

Linux on x86_32 (32-bit) sapjco21P_10-20007301.zip

Linux on x86_64 (64-bit) sapjco21P_10-20007300.zip

Linux on zSeries (64-bit) sapjco21P_10-10002245.zip

Linux on Power® (64-bit) sapjco21P_10-20007302.zip

2. Back up the following directory: $COLLATION_HOME/lib/JCo/operating_system.3. Copy the following files from the package to the following directories:

For UNIX or Linux operating systems:

• librfccm.* to $COLLATION_HOME/lib/JCo/operating_system• libsapjcorfc.so to $COLLATION_HOME/lib/JCo/operating_system• sapjco.jar to $COLLATION_HOME/lib/JCo/operating_system/lib

For Windows operating systems:

• librf32.dll to $COLLATION_HOME/lib/JCo/operating_system• sapjcorfc.dll to $COLLATION_HOME/lib/JCo/operating_system• sapjco.jar to $COLLATION_HOME/lib/JCo/operating_system/lib


Run the ldd command against the libraries to see the dependencies, and ensure that the dependenciesare supported. The base operating system supports most of the dependencies.

On the Linux operating system, the libstdc++-libc6.2-2.so.3 library might not be installed bydefault. In that case, you must install the Red Hat package compat-libstdc++-296 to get the libstdc++-libc6.2-2.so.3 library files.

If the library dependencies are not supported, the following message is shown:

Sensor failed in remote server: JCO.classInitialize (): Could not load middleware layer 'com.sap.mw.jco.rfc.MiddlewareRFC' JCO.nativeInit (): Could not initialize dynamic link library sapjcorfc [Can't find library sapjcorfc (libsapjcorfc.so) in sun.boot.library.path or java.library.path sun.boot.library.path={full-path-list}



1. Select Computing Center Management System (CCMS) as the Component Type.2. Specify the following required information:

a. User name (The user name must have at least all the authorizations mentioned in the following list)b. Passwordc. Client ID


The following lists the authorizations that are required by the SAP user being used for CCMS sensordiscovery. Grant all (*) privileges to the following authorization objects:

S_RFCAuthorization Check for RFC Access

S_ADMI_FCDSystem Authorizations

S_DATASETAuthorization for file access.The minimum permissions are:

• READ• READ with FILTER

Important: Do not grant all (*) permissions.

S_LOG_COMAuthorization to Execute Logical Operating System Commands

S_RZL_ADMCC Control Station: System AdministrationThe minimum permissions are:

• DISPLAY

Important: Do not grant all (*) permissions.

S_XMI_LOGInternal Access Authorization for XMI Log

S_XMI_PRODAuthorization for External Management Interfaces (XMI)






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


The following errors occur, which means that the class path does not contain the path for thesapjco.jar file:

Sensor failed in remote server: com/sap/mw/jco/JCOMSG_ERROR: java.lang.NoClassDefFoundError: com/sap/mw/jco/JCO


SolutionThe sapjco.jar file should be in the $COLLATION_HOME/lib/JCo/lib directory, this file pathshould be in the class path.

Look for the following message in the DiscoverManager.log file:

adding this jar file to the list: {jar-file-path}

The jar-file-path should be $COLLATION_HOME/lib/JCo/lib/sapjco.jar.

Sensor cannot find library fileProblem

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

Sensor failed in remote server:JCO.classInitialize (): Could not load middleware layer'com.sap.mw.jco.rfc.MiddlewareRFC'JCO.nativeInit (): Could not initialize dynamic link library sapjcorfc[Can't find library sapjcorfc (libsapjcorfc.so) in sun.boot.library.pathor java.library.path sun.boot.library.path={full-path-list}

SolutionEnsure that the libsapjcorfc.so library file is in the $COLLATION_HOME/lib/JCo/operatingsystem path.

This library file must be of the 64-bit version, because the TADDM servers, or anchors, or both, in theTADDM environment are running a 64-bit operating system.

Also ensure that this path is present in the full-path-list for sun.boot.library.path that ismentioned in the error message. If the path is present, the problem might be due to librarydependencies that have not been met. Run the ldd command against the libsapjcorfc.so libraryfile to get a list of the library dependencies, and verify that your environment supports thesedependencies.

No CCMS access list is provided for an IP addressProblem

The following error occurs:

ERROR collation. AnchorClient - No CCMS access list provided for:{ip-address}

This error can occur for one of the following reasons:

• No access list is provided for the sensor.• The sensor cannot successfully connect to the IP address using the access list information that is

provided by the user.

SolutionIf you provided the necessary access list credentials, verify the following items:

• Ensure that the user ID meets the specified minimum authorization requirements.• Ensure that the SAP ABAP server is accessible.• Look for the following message in the local-anchor*.log, and ensure that the username and

client-id that are specified are the ones that you set:

Checking connection with username: {username} and clientID: {clientid}

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


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

Sensor name that is used in the GUI and logsSLDServerSensor

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

Depending on the specific application of SAP NetWeaver systems, you can use the SAP CCMS serversensor, the SAP SLD server sensor, or both to discover this system. SAP applications are installed on twodifferent database schemas depending on the application, and each are accessed by their respectiveruntime environments. There is a runtime environment for Java instances (Java stack) and one for theAdvanced Business Application Programming (ABAP) instances (ABAP stack):

• Use the SAP CCMS server sensor to discover information where the SAP NetWeaver system hasapplications based only on the ABAP stack.

• Use the SAP SLD server sensor to discover information where the SAP NetWeaver system hasapplications based only on the Java stack.

• Use the SAP CCMS server sensor, the SAP SLD server, or both sensors to discover information where theSAP NetWeaver system has applications based on both the ABAP and Java stacks.

Note: If you want to change the SLD port, other than the default listed port, then you can setthe new portlist in sensor configuration panel. SLD connection will be established with the new listedports.

Model objects with associated attributesThe SAP SLD server sensor creates model objects with associated attributes. The attributes indicate thetype of information that the sensor collects about the SAP systems, SAP servers (ABAP and Java), andSAP components in your IT environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.AppConfig

• Content• Parent

DatabaseServer

• HierarchyDomain• HierarchyType• Host• OpenId• ProductVersion• VendorName

In TADDM 7.3.0.2, and later, the SAP SLD server sensor discovers also other databases than Oracle,DB2, and MS SQL Server databases. For example, it discovers the SAP HANA database. The sensorcreates a new type of model object for them, DatabaseServer. To distinguish the databases insidethis class, the hierarchyDomain and hierarchyType attributes are set for each object. Forexample, the attributes are set to the following values for the HDB object:

hierarchyDomain="app.db.hdb.mysap"hierarchyType="HDBDatabaseServer"


FunctionalGroup

• App• GroupName• Members

MySAPABAPApplicationServer

• BasisAppSystemNumber• Host• KeyName• MySAPKernelRelease• PrimarySAP• ProcessPools• ProductName• SAPSystemSID• Status• SystemHome

MySAPCluster

• SAPSystemSID• Servers• Status• SystemHome

MySAPClusterNode

• ClusterNodeID• Parent• Type

MySAPDb2Instance

• Host• Owner• ProductVersion• SAPSystemSID• SID• SystemHome• VendorName

MySAPJ2EEEngineInstance

• ClusterNodes• ConfigContents - this attribute is available only for the MySAPJ2EEEngineInstance object for which

the sensor was started• Host• JavaInstanceId• IsSDM• PrimarySAP - this attribute is available only for the MySAPJ2EEEngineInstance object for which the

sensor was started• ProcessPools - this attribute is available only if the MySAPJ2EEEngineInstance object is a member

of the SAPSystem object


• SAPSystemSID• Status - this attribute is available only if the MySAPJ2EEEngineInstance object is a member of the

SAPSystem object• SystemHome• VersioningAndPatchInfo

MySAPJavaCentralSystem

• ClusterNodes• Host• JavaInstanceId• IsSDM• ProcessPools - this attribute is available only if the MySAPJavaCentralSystem object is a member of

the SAPSystem object• SAPSystemSID• Status - this attribute is available only if the MySAPJavaCentralSystem object is a member of the

SAPSystem object• SystemHome• VersioningAndPatchInfo

MySAPOracleInstance

• Home• Host• HostName• Owner• ProductVersion• SAPSystemSID• SID• SystemHome• VendorName

MySAPSqlServer

• Host• KeyName• Owner• ProductName• ProductVersion• SAPSystemSID• SID• SystemHome• VendorName

ProcessPool

• Name• Parent• RuntimeProcesses

RuntimeProcess


SAPComponent

• Description• HighestSupportPackage• Name• Parent• PatchLevel• Release

SAPSystem

• AppVersion• BasisVersion• Contact• DeployedComponents• Description• Groups• InstallationNumber• LicenseExpiryDate• Name• SAPSystemSID• SystemHome• Vendor




1. Select System Landscape Directory Server as the Component Type.2. Enter the following required information, User name and Password.

You must assign the SAP_SLD_GUEST and the SAP_J2EE_GUEST roles to the SAP account, anddepending on your configuration, you might also need to assign the SAP_J2EE_ADMIN role to the SAPaccount.


com.collation.discover.agent.SLDServerAgent.connectionTimeout=30The default value is 30, which means 30 seconds. The value must be an integer.

This property specifies the maximum amount of time (in seconds) to wait for the initial SLDconnection test.

Connection timeouts are recorded in the DiscoveryManager.log file. If these timeouts occur,increase the value of this property.

The property can be scoped to a specific host name or IP address, as shown in the followingexamples:

com.collation.discover.agent.SLDServerAgent.connectionTimeout.Linux.1.2.3.4=60


com.collation.discover.agent.SLDServerAgent.connectionTimeout.SunOS=45





com.collation.discover.agent.SLD.PoolSizeThis property specifies the maximum number of connection pools to be maintained alive to an SLDserver. These connections can be reused for additional requests. The default value is 16.

com.collation.sudoCommandThis property specifies the sudo command name. The default value is sudo.

Troubleshooting the sensorThis topic describes common problems that occur with the SAP SLD server sensor and presents solutionsfor those problems.

SLDServerAgent connection timeout errorsProblem

SLDServerAgent connection timeout errors are found in the DiscoverManager.log file.Solution

In the $COLLATION_HOME/etc/collation.properties file, increase the value of thecom.collation.discover.agent.SLDServerAgent.connectionTimeout property until theconnection is successful.

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

Sensor name that is used in the GUI and logsSMBServerSensor


• sys.ServiceAccessPoint• sys.SMBExport• sys.SMBSAP• sys.SMBService


Troubleshooting the sensorThis topic describes common problems that occur with the SMB server sensor and presents solutions forthose problems.

Error message uncaught exception results when running a discoveryProblem

The following message is displayed when running a discovery:

Uncaught exception invoking GetSystemInfo: System.NullReferenceException: Object reference not set to an instance of an object

SolutionThis message indicates that there is a problem with Windows Management Instrumentation (WMI)service. For information about WMI problems and solutions, see the Windows computer systemsensor “Troubleshooting the sensor” on page 366 topic.

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

Sensor name that is used in the GUI and logsSMSServerSensor

LimitationsThe sensor does not discover information about SMS Server client computer systems as CDMComputerSystem 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 arepart of the SMS Server infrastructure.


• app.sms.SMSAdvertizements• app.sms.SMSCollections• app.sms.SMSCollectionClients• app.sms.SMSHierarchy• app.sms.SMSPackage• app.sms.SMSProgram• app.sms.SMSQuery• app.sms.SMSReports• app.sms.SMSResource• app.sms.SMSServerProcess• app.sms.SMSSiteBoundaries• app.sms.SMSSiteComponents• app.sms.SMSSiteServer




com.collation.discover.agent.SMSServerAgent.GetReportsIf set to true, SMS Report information is captured by the sensor and stored as instances of the CDMSMSReports class. The default value is false.

com.collation.discover.agent.SMSServerAgent.GetQueriesIf set to true, SMS predefined queries are captured by the sensor and stored as instances of the CDMSMSQuery class. The default value is false.

com.collation.discover.agent.SMSServerAgent.GetClientsIf set to true, information about SMS collection clients is captured by the sensor and stored asinstances of the CSM SMSCollectionClients class. The default value is false.

com.collation.discover.agent.SMSServerAgent.MaxNrClientsThe maximum number of clients about which information is captured by the sensor. The default valueis 100.

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

Sensor name that is used in the GUI and logsSysImagerServerSensor and SysImagerNodeSensor

PrerequisitesThe GenericComputerSystemSensor, along with prerequisite sensors, must be enabled in the discoveryprofile used for discovering the SysImager cluster.


• sys.hpc.cm.ConfigurationManagementCluster• sys.hpc.cm.ConfigurationManagementNode• sys.hpc.cm.ConfigurationMangementNodeGroup• sys.hpc.cm.ConfigurationManagementClusterConfigFile• sys.hpc.cm.SysImagerNode• sys.hpc.cm.SysImagerNodeImage• sys.hpc.cm.SysImagerOverride



To configure the discovery profile, complete the following steps:

1. Create a discovery profile and select agent configuration of type SysImagerServerAgentConfiguration.2. Set the following required attributes:

masterServerNamesThe IP addresses or host names of SysImager master nodes. This property must be set to start theSysImager server sensor.

3. If appropriate, set some of the following attributes, or accept the default values.


configFileLocationThe location of the SysImager configuration file. The default value is /etc/systemimager/systemimager.conf.

clusterXMLFileLocationThe location of the SysImager cluster configuration file. The default value is /etc/systemimager/cluster.xml.

clusterConfigCommandThe command to display configuration information about the SysImager cluster. The default valueis si_clusterconfig -g.

lsImageCommandThe command to display images of the SysImager cluster. The default value is si_lsimage -v.

imagesDiscoveryModeThis property is not used.

overridesDiscoveryModeThe depth of file capture for overrides. The valid values are as follows:

• 0: No file information is captured.• 1: Only the file name and file information are captured.• 2: All file information and content are captured.


overridesDiscoveryPatternThe filename pattern for files under the overrides directory. The default value is "*".

preInstallScriptsContentThe depth of file capture of the scripts executed before install. The valid values are as follows:



postInstallScriptsContentThe depth of file capture of the scripts executed after install. The valid values are as follows:



nodesScopeThe scope of the IP addresses to which the SysImager node sensors are restricted.

doPingNodesSpecifies whether ping sensors are run against discovered SysImager nodes.


SysImagerServerSensor uses SysImager Server access entry. If this is not available, the sensor usesComputerSystem access entry to access the SysImager server.

SysImagerNodeSensor uses ComputerSystem access entry to access SysImager nodes.


Veritas cluster sensorThe Veritas cluster sensor discovers Veritas Cluster Servers.

The sensor collects general information about the Veritas Cluster Server and the services that areinstalled on it. Services are organized in service groups and contain information about the resources thatare used.

The sensor can create relationships between the services and applications installed on a cluster.

Sensor name that is used in the GUI and logsVeritasClusterSensor

Security issuesThe user account for discovering Computer Systems is also used for running Veritas commands. Bydefault, execute permission on the Veritas Cluster directory and commands is required. The sensor usesthe following commands:

• hastatus• haclus• hasys• hares• hagrp• hatype• hauser

Before running Veritas commands, a login to the cluster is performed on systems that support the Veritashalogin command. These are UNIX systems with VCS version 4.1 and higher. The sensor logs in using theuser 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 orUNIX 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 memberof the Veritas Admin Group on the target.

The following commands should be executed manually on Veritas target to check if there isenough permission to discover VeritasClusterSensor successfully:

• halogin [user] [password]• halogout -endallsessions• halogout -endsession localhost• haclus -display• hasys -display• hares -dep• hares -display• hagrp -resources [group]• hagrp -dep [group]• hagrp -display• hatype -display

You must configure sudo ndd with NOPASSWORD for the access user.



• app.ConfigFile• app.SoftwareInstallation• app.veritas.cluster.VCSCluster• app.veritas.cluster.VCSHADServer• app.veritas.cluster.VCSLocalServiceGroup• app.veritas.cluster.VCSResourceConfiguration• app.veritas.cluster.VCSServiceGroup• app.veritas.cluster.VCSSystem



The following VeritasClusterSensor attribute can be modified:discoveryMode

The default value for the discoveryMode attribute is 1 (the sensor runs in lightweight mode).

To generate more configuration items and store them in the database, specify 0.

Alternatively, open the $COLLATION_HOME/etc/discover-sensors/VeritasClusterSensor.xmland modify the attribute.

When you use both Veritas cluster sensor and Oracle sensor to discover an Oracle instance, duplicatesmight occur. This happens because Veritas cluster sensor uses the upper case for the instance SID andOracle sensor uses the lower case for the same SID. To avoid this problem, modify the dist/etc/discover-sensors/VeritasClusterSensor.xml file by changing the following line:

<source>Sid</source>

into the following line:

<source>%{Sid}</source>

After the change, Veritas cluster sensor creates Oracle instances with the lower case SID.

Note: If you change the line after running discoveries where no duplicates occurred, new duplicates mightoccur.



1. Select High Availability Solutions as the Component Type.2. Enter the following required information, User name and Password.


The following properties specify that the sensor uses sudo to elevate privileges when running VeritasCluster Server commands:

• com.collation.discover.agent.command.hastatus.Linux=sudo /opt/VRTSvcs/bin/hastatus


• com.collation.discover.agent.command.haclus.Linux=sudo /opt/VRTSvcs/bin/haclus

• com.collation.discover.agent.command.hasys.Linux=sudo /opt/VRTSvcs/bin/hasys• com.collation.discover.agent.command.hares.Linux=sudo /opt/VRTSvcs/bin/hares• com.collation.discover.agent.command.hagrp.Linux=sudo /opt/VRTSvcs/bin/hagrp• com.collation.discover.agent.command.hatype.Linux=sudo /opt/VRTSvcs/bin/hatype

• com.collation.discover.agent.command.hauser.Linux=sudo /opt/VRTSvcs/bin/hauser

You can scope each property to a specific operating system or IP address, as in the following examples:

• com.collation.discover.agent.command.hastatus =sudo /opt/VRTSvcs/bin/hastatus• com.collation.discover.agent.command.hastatus.Linux=sudo /opt/VRTSvcs/bin/hastatus

• 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 operatingsystem; otherwise, specify the option only for the specific IP addresses where the sudo command isconfigured. 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 theNOPASSWD option. Otherwise, your discovery hangs until the TADDM server times out.

Troubleshooting the sensorThis topic describes common problems that occur with the Veritas cluster sensor and presents solutionsfor those problems.

The sensor failsProblem

The VeritasClusterSensor sensor fails.Solution

If the sensor fails and the logs point to some of the commands timing out, this error could indicate afailed login to the cluster. Verify that the correct user name and password for the Veritas Cluster isused.

VMware Virtual Center server sensorThe VMware Virtual Center server sensor discovers VMware Virtual Center servers and the elements thatare managed by the servers. VMware Virtual Center is now known as VMware vCenter Server.

Sensor name that is used in the GUI and logsVirtualCenterSensor

Elements discovered by the sensorThe sensor discovers the following elements that are managed by the Virtual Center server:

• CPU resource pools• Data centers in a virtual center• Data store extents for VMware vSphere 4• Data stores that are created in each data center• Distributed virtual switches, uplinks, and port groups in each distributed virtual switch


• Memory resource pools• Serial number of ESX servers• Virtual switches and port groups in each virtual switch• VMware clusters that are created in each data center• VMware ESX servers that are managed by a virtual center• IP Addresses for Virtual Machines

VMware ESX servers, which are discovered by the VMware ESX and Virtual Center server sensors, aremerged after the discovery.

In the Discovery Management Console, a VM (virtual machine) is represented by a computer system iconthat is blue and transparent.

The Virtual Center server sensor uses the VMware API to discover data, and the VMware API collects thefollowing data:

• Attribute data that is required to match naming rules and to create a valid stand-alone VM instance• Certain basic information that the VMware ESX server provides through the vmware-cmd command• The attribute primaryMACAddress, which is required to reconcile the shallow virtual instance with any

physical instance that can be discovered• 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:

• 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 VirtualCenter servers are displayed in one of the data centers or clusters in the virtual center. All virtual andphysical instances, discovered by the Virtual Center and ESX sensors are reconciled. The physicalinstances have a virtual attribute set to true.

• 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 typicalattributes for example, model are displayed. The Virtual Center sensor is not started.

• 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 Centersensor.

• 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. Thevirtual computers are displayed in the Virtual Systems tab of the respective ESX server.

PrerequisitesThe VMware Virtual Center server service is running on the target windows computer. The VMware VirtualCentre server sensor may be started by listening port, by process template match or both. By default,sensor is started by process template match.

Restriction: This prerequisite does not apply to vCSA (Virtual Center Server Appliance). vCSA is based onLinux technology and will be detected by TADDM using standard permissions, without the need for furtherprerequisites.

For successful discovery of VMware vCenter Server Appliance 6, ports for Web Servicescommunication must be defined. By default, ports 80 and 443 are defined. If your VMware vCenter ServerAppliance 6 uses non-standard ports, modify the value of the portList property in the discovery profile.For details, see “Configuring the discovery profile” on page 147.


Support discovery of Virtual Center System Appliance through web portsThis enhancement can allow you to discover VCSA using web interfaces. There is a new configurationoption in Port sensor to allow the specification of VCSA listening ports (vcsaListeningPortList) to be usedto trigger seeding of VirtualCenterSensor.

Limitations• If port mentioned in `vcsaListeningPortList` is opened by some process other than VCSA, the VMware

Virtual Center server sensor will show error.

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

Connection to servers with SSLThe VMware Virtual Center server sensor can connect to servers with SSL in two modes - the defaultmode and a new mode.The default mode

The default mode does not fully verify the certificate of a server. This mode allows connection even ifthe certificate is self-signed, expired or with an invalid host name. It rejects connection when otherproblems are found, like certificate chaining error. The default mode can be used with the defaultVMware certificates.

The new modeThe new mode fully verifies the certificate of a server. You can enable this mode by setting thestrictCertificateCheck configuration property to true. When this mode is enabled, only validcertificates signed by trusted certificate authorities are accepted.

Importing self-signed certificates to TADDMBy setting the strictCertificateCheck property to true, you can connect with self-signedcertificates. You must first import such a certificate to TADDM. Though self-signed certificates aretrusted certificates, their validity is still verified.To import such certificates, complete the following steps:

1. Open the taddm/dist/osgi/plugins/com.ibm.cdb.discover.sys.vmware.vmwarecommon_* directory, where * is the versionnumber of the sensor.

2. Run the following command:

java -cp lib/vmwarecommon.jar com.ibm.cdb.discover.sys.vmware.VmCertificateCollector ip:port

where ip is the IP address of the VMware Virtual Center server sensor host, and port is the SSL portof that host.

Recommended ConfigurationYou should select the configuration port logically to avoid any false seeding of the VirtualCenterSensor(VCSA). It works best if these ports are acknowledged to a unique virtual center. If there is a specific list ofports, the listed ports shall specify the same listeners. These ports take account of the configurationchanges on instances to avoid the collision.Example:

1. Example: 80 TCP vCenter Server requires port 80 for direct HTTP connections. Port 80 redirectsrequest to HTTPS port 443. This redirection is useful if you unintentionally use http://serverinstead of https://server.


2. 443 TCP Default port that the vCenter Server system uses to listen for connections from thevSphere Web Client. To enable the vCenter Server system to receive data from the vSphere WebClient, open port 443 in the Firewall.

Ports 80,443 are ubiquitous ports and may appear a bad choice for seeding the VirtualCenterSensor,since they can cause many false positives for sensor invocations. It is recommended to provisionmore unique port (or lists of that port's possible values in a customer deployment) that shall be usedin PortSensors `vcsaListeningPortList`.

1. 514 TCP/UDP vSphere Syslog Collector port for vCenter Server on Windows and vSphere SyslogService port for vCenter Server Appliance.

2. 902 TCP/UDP Default port that the vCenter Server system uses to send data to managed hosts.Managed hosts also send a regular heartbeat over UDP port 902 to the vCenter Server system. Thisport must not be blocked by firewalls between the server and the hosts or between hosts.

Model objects with associated attributesThe VMware Virtual Center server sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about VMware Virtual Center resources in your ITenvironment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.dev.StorageExtent

• ManagedSystemName• Name

net.IpInterface

• Name (for ESX server only)• IpAddress

net.L2Interface

• Name (for ESX server only)• HwAddress

process.CPUResourcePool

• Name• Label• Limit• Reservation• SharesLevel• SharesValue

process.MemoryResourcePool

• Name• Label• Limit• Reservation• SharesLevel• SharesValue

relation.AllocatedTo

• Source (MemoryResourcePool or CPUResourcePool)


• Target (Memory or CPU)

relation.DonatedTo

• Source (for ESX server only)• Target (MemoryResourcePool or CPUResourcePool)

sys.CPU

• NumCPUs• Parent

sys.DNSResolveEntry (for ESX server only)

• ServerIP• Parent

sys.Memory

• MemorySize• Parent

sys.NFSFileSystem

• serverName• MountPoint• Type• Capacity• AvailableSpace• MaxFileSize• StorageExtent• FileSystemBlockSize• MaxBlocks

sys.unix.UnixFileSystem (for Virtual Machine File System)

• MountPoint• Type• Capacity• AvailableSpace• MaxFileSize• StorageExtent• FileSystemBlockSize• MaxBlocks

sys.vmware.DataCenter

• Name• Label• Parent• Systems• Clusters• VirtualSwitches

sys.vmware.VirtualCenter

• Name


• Host• UID• VersionString• ApiVersion• Vendor• BuildLevel• VirtualCenterPort• MaxDBConnections• ClientTimeoutNormal• ClientTimeoutLong• WebServiceHttpPort• WebServiceHttpsPort

sys.vmware.VMWareCluster

• Name• Label• DPMEnabled• DRSEnabled• HAEnabled• Parent• RootMemoryResourcePool• RootCPUResourcePool

sys.vmware.VMWareDataStore

• Name• Label• Type• DataStoreURL• Capacity• FreeSpace• IsAccessible• AccessMode• IsMultipleHostsAccess• BasedOn• DataCenter

sys.vmware.VmwareESX

• OSName• OSVersion

sys.vmware.VMWarePortGroup

• ActiveUplinks• L2Interfaces• Name• Parent• StandbyUplinks


• Uplinks

sys.vmware.VmwareUnitaryComputerSystem

• Name• Fqdn• ObjectType• Manufacturer• Model• CPUSpeed• CPUType• LifecycleState• NumCPUs• MemorySize• AvailableMemoryForAllVMs• CurrentMemoryForAllVMs• SwapMemorySize• ServiceConsoleMemorySize• VmotionEnabled

sys.vmware.VMWareVirtualSwitch

• DataCenter• Name• MTU• NumPorts• NumPortsAvailable• ObjectType• PortGroups• Parent• UplinkPortGroups• Interfaces

sys.vmware.VMWareDVUplink

• L2Interfaces• Name

Multiple virtual machines, such as the following operating systems and virtual systems:

sys.darwin.Darwinsys.darwin.DarwinUnitaryComputerSystemsys.dos.Dossys.dos.DosUnitaryComputerSystemsys.freebsd.FreeBSDsys.freebsd.FreeBSDUnitaryComputerSystemsys.linux.Linuxsys.linux.LinuxUnitaryComputerSystemsys.netware.Netwaresys.netware.NetwareUnitaryComputerSystemsys.sun.Solarissys.sun.SunSPARCUnitaryComputerSystem


sys.windows.WindowsComputerSystemsys.windows.WindowsOperatingSystem


• uuid• VMID• OSName• Fqdn (if VMware Tools are running on virtual machine)• MemorySize• NumCPUs• FaultTolerance

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

Configuring non-administrator users to run the sensorNon-administrator user accounts must have permission to run the VMware Virtual Center server sensor.You can assign the required permissions using the VMware Infrastructure Client.

Note: Administrator accounts have the necessary permission by default and do not require thisprocedure.

To assign the required permissions to a non-administrator user account, complete the following steps:

1. From the VMware Infrastructure Client, log on to the VMware Virtual Center server using anadministrator account.

2. Click the Permissions tab.3. Assign the Read-Only role to the non-administrator user account you want to have permission to run

the sensor. For more information about how to assign roles to users, see the VMware documentation.

Configuring the discovery profileBy default, the VMware Virtual Center server sensor is enabled for a Level 3 discovery. The sensordiscovers all guests including guest systems that are powered off. To discover only guest systems that arerunning, create a Level 3 discovery profile for the VMware Virtual Center server sensor, and customize thesensor settings.



profile list, select Level 3 Discovery and click OK.4. On the Sensor Configuration tab, select the VirtualCenterSensor sensor and click New.5. In the Create Configuration window, type the name and description for your configuration, and select

the Enable Configuration check box.6. In the Configuration section of the Create Configuration window, click discoverNonRunningGuests.

Then, double-click the Value field in the row, and type false.7. Click OK to return to the Discovery Profiles window.8. In the Discovery Profiles window, click Save.

PropertiesYou can modify the following properties:


ordinalESXviaVCserialDiscoveryIt discovers a serial number by using VMware API. This is a standard way to discover the serialnumber, it is faster than by using CIM API, it requires fewer privileges, but is also more prone toerrors.The default value is false.

directESXserialDiscoveryIt discovers a serial number by using CIM API. This method always discovers the serial number, but isslower and the following requirements apply:

• The discovery user must have the Host > CIM > CIMInteraction privilege.• The connection between TADDM and the ESX server is required.

For more information, see also a technote at http://www-01.ibm.com/support/docview.wss?uid=swg21638454.

Important: If you run the ESX server on virtualized hardware like Cisco UCS, you must discover theserial number by using CIM API, not VMware API, because otherwise over merges might occur.

The default value is false.shallowVMdiscovery

It discovers limited data for Virtual Machine.The default value is false.

discoverNonRunningGuestsIt discovers not running Virtual Machines.The default value is true.

strictCertificateCheckIt forces the sensor to connect to VirtualCenter servers that are secured with valid, CA signedcertificates.The default value is false.

enableVMDiscoveryIt enables the discovery of Virtual Machines.The default value is true.

shallowESXDiscoveryIt enables shallow ESX discovery. ESX servers are discovered only with a name, datastore information,and relations to datacenter. It can be used with ESXi sensor for faster discovery of the wholeenvironment.The default value is false.

portListIt contains a comma-separated list of ports that are used by VMware vCenter Server Appliance 6 forWeb Services communication. Modify the value of this property if your VMware vCenter ServerAppliance 6 uses non-standard ports.The default value is 80,443.


To configure the access list, enter the following information:

• To access the VMware Virtual Center server using an account with administrator privileges:

1. Use ComputerSystem (Windows) as the Component Type.2. Specify the access information (user name and password).

Use this method to grant access to the host computer system and the VMware Virtual Center server.

• To access the VMware Virtual Center server using an account with read-only privileges:


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


1. Use Virtual Center Server as the Component Type.2. Specify the access information (user name and password).

Use this method to discover VMware Virtual Center servers in an IBM Tivoli Monitoring environment.This method grants access to the Virtual Center server only and does not grant access to the hostcomputer system. In the discovery profile include the VMware Virtual Center server sensor and theIBM Tivoli Monitoring Scope sensor.

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

The sensor uses the following entries in the collation.properties file:com.collation.platform.os.UnixOs.forcedServerList=vpxd

You must add the vpxd server process in the property to ensure that the VirtualCenter server sensorstarts. For example,

com.collation.platform.os.UnixOs.forcedServerList=vxconfigd;clstrmgr;vpxd

Note: TADDM applies Custom Server matching templates only to server processes. These processes arelistening either on TCP port or on Windows Services. You can force a programme name usingcom.collation.platform.os.UnixOs.forcedServerList=vpxd property in thecollation.properties. If the vpxd process is not listening on TCP port, you must add this property.

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

Serial number and System ID are blank in the Details panel of the VMware ESXserverProblem

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.

SolutionTADDM uses SMASH API to connect directly to the ESX server. Make sure that the connection is openfor the port that is specified in the com.collation.discover.vmware.cimport property (bydefault, it is 5989), or use an anchor instead. ESX must support SMASH API.

Verify that the ESX server and Virtual Center server are included in the discovery scope. Check thecredentials, to ensure that the correct permissions are used for accessing the ESX server and VirtualCenter server, and run the discovery again. For the L2Interface layer, the sensor only collects thename and hardware addresses.

The sensor fails with a timeout errorProblem

If the Virtual Center server is managing many ESX hosts and virtual computers then the sensor can failwith a timeout error message, An error occurred. Sensor timed out.

SolutionIn the etc/collation.properties file, increase the value for the sensor to run, where value is thenumber of milliseconds allowed for the sensor to run:

com.collation.discover.agent.VirtualCenterSensor.timeout=value

The default value is 3600000 .


Elements managed by the VMware Virtual Center server are not discoveredProblem

Elements are not discovered on VMware vCenter Server Version 4.1 running on Microsoft WindowsServer 2003. The following error messages exist:

• The VirtualCenterServer log contains:

AxisFault faultCode: {http://xml.apache.org/axis/}HTTP faultSubcode: faultString: (503)Service Unavailable faultActor: faultNode: faultDetail: {}:return code: 503503 Service Unavailable {http://xml.apache.org/axis/}HttpErrorCode:503 (503)Service Unavailable )

• The VMware Virtual Center server vpxd log contains:

Connection to localhost:8085 failed with error class Vmacore::SystemException(Normally allowed each socket address (protocol / network address / port) is used only once.

• Running a netstat -ban | findstr 8085 command from the VMware Virtual Center servershows many TCP/IP Ports are left open in a LAST_ACK state.

SolutionThe behavior occurs because ephemeral ports, temporary ports that are used for client servercommunications, are not closed upon use. Ephemeral ports are limited to a range of ports and areonly valid for the duration of the connection. In this case, on certain Microsoft Windows operatingsystems, certain connections leave the ports in a LAST_ACK state on the Virtual Center server. Therange of ports can be exhausted after a time and when this situation happens, connectivity can failuntil a port is freed.

To prevent this event occurring, go to the Microsoft website at http://support.microsoft.com andsearch for KB979230. You can then download and install the fix.

WebLogic sensorThe WebLogic sensor discovers Oracle WebLogic Server application servers and WebLogic Server versioninformation.

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

Sensor name that is used in the GUI and logs• WeblogicSensor• WeblogicSensor2• WeblogicServerVersionSensor

PrerequisitesThe WeblogicSensor sensor requires additional JAR files that are part of the Oracle WebLogic Serverinstallation. You must copy these JAR files to the following directories on the TADDM server:

• For Linux, AIX, and Linux on System z operating systems:

– $COLLATION_HOME/lib/weblogic/9.0– $COLLATION_HOME/lib/weblogic/10.0

• For Windows operating systems:

– %COLLATION_HOME%\lib\weblogic\9.0– %COLLATION_HOME%\lib\weblogic\10.0


http://support.microsoft.com

You must configure the specific name of the $COLLATION_HOME/lib/weblogic/$VERSION_DIRdirectory 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 theWeblogicVersionSensor.xml file.

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

LimitationsTADDM 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 discoveryprofile.


• app.AppConfig• app.AppServer• app.ConfigFile• app.j2ee.weblogic.WebLogicServer• app.j2ee.J2EEComponent• app.j2ee.J2EEDeployedObject• 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• app.j2ee.weblogic.WebLogicSSLSettings• app.j2ee.weblogic.WebLogicServer


• app.j2ee.weblogic.WebLogicServlet• app.j2ee.weblogic.WebLogicVirtualHost• app.j2ee.weblogic.WebLogicWebContainer• app.j2ee.weblogic.WebLogicWebModule• app.ProcessPool• app.SoftwareContainer• app.web.WebVirtualHost

Configuring the sensorBefore using the WebLogic sensor, you must configure it.

Copying JAR files to the TADDM serverYou must copy additional JAR files that are part of the Oracle WebLogic Server installation to the TADDMserver.

Before starting a discovery, copy the required JAR files for your WebLogic version to the$COLLATION_HOME/lib/weblogic/$VERSION_DIR/ directory:

Table 14. Required WebLogic JAR files

WebLogic version Required JAR files

WebLogic version 9 (all releases) • $WEBLOGIC_HOME/server/lib/weblogic.jar• $WEBLOGIC_HOME/server/lib/webservices.jar• $WEBLOGIC_HOME/server/lib/wljmxclient.jar

WebLogic version 10.0 through10.2

WebLogic version 10.3 • $WEBLOGIC_HOME/server/lib/wlfullclient.jar

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

Creating a wlfullclient.jar for the WebLogic sensorYou must create a wlfullclient.jar file for a client application. This JAR file is required for WebLogicversion 10.3, or later.

To create a wlfullclient.jar file for the WebLogic sensor, complete the following steps:

1. Change to the directory where the WebLogic Server is installed:

cd WL_HOME/server/lib

2. Create the wlfullclient.jar file:

java -jar ../../../modules/com.bea.core.jarbuilder_X.X.X.X.jar

where X.X.X.X is the version number of the JarBuilder module in the WL_HOME/server/libdirectory. For example:

java -jar ../../../modules/com.bea.core.jarbuilder_1.0.1.0.jar

3. Copy and bundle the wlfullclient.jar file with the client application.4. Add the wlfullclient.jar file to your Java class path.

Editing the WeblogicVersionSensor.xml fileYou must edit the WeblogicVersionSensor.xml file.

The configuration file is located in the following directories:


• On Linux, Solaris, AIX, and Linux on System z operating systems, the file is in the$COLLATION_HOME/etc/discover-sensors/ directory.

• On Windows operating systems, the file is in the %COLLATION_HOME%\etc\discover-sensors\directory.

The code sample in this section shows how to configure the directories and Java runtime environment(JRE) using XML tags. In this example, the following directories and JRE pairs are configured:

• The JAR files from the lib/weblogic/10.0 directory are paired with the Java SDK version 1.5.0 JRE.• The JAR files from the lib/weblogic/9.0 directory are paired with the Java SDK version 1.5.0 JRE.

The <entry> tag configures the directory name used to store the WebLogic JAR files. The WebLogic JARfiles must be located in the lib/weblogic directory.

Similarly, the <jdk> tag configures the version of the Java SDK in use. The only valid value is 1.5.0. If theWeblogicServerVersionSensor sensor does not recognize the BEA WebLogic server that is running, youcan use the <WeblogicClassPathDefault> tag to force a configuration.

<SensorPlugin xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.ibm.com/xml/schemas/taddm/FixedSensorSchema.xsd"> <name>WeblogicServerVersionSensor</name> <osgiId>com.ibm.cdb.discover.sensor.app.j2ee.weblogicserverversion_7.1.0</osgiId>

<sensorClassName>com.collation.discover.agent.app.j2ee.WeblogicServerVersionAgent</sensorClassName> <seedClassName>com.collation.discover.seed.app.j2ee.WeblogicVersionSeed</seedClassName> <resultClassName>com.collation.discover.result.app.j2ee.WeblogicVersionResult</resultClassName> <convertorClassName>com.collation.discover.engine.seedfactory.WeblogicVersionConvertor</convertorClassName>

<defaultProfiles> <profile>Level 3 Discovery</profile> </defaultProfiles> <configuration className="com.ibm.cdb.discover.sensor.configuration.WeblogicServerVersionAgentConfiguration"> <weblogicClassPath> <item> <entry>10.0</entry> <jdk>1.5.0</jdk> </item> <item> <entry>9.0</entry> <jdk>1.5.0</jdk> </item> </weblogicClassPath>  </configuration></SensorPlugin>

In the sample, the WeblogicServerVersionSensor sensor uses JAR files from the lib/weblogic/10.0directory with the JRE from the Java SDK version 1.5.0 and assumes that WebLogic Server 10.x isrunning.

Editing the WeblogicSensor2.xml fileYou must edit the WeblogicSensor2.xml file.

The configuration file is located in the following directories:

• On Linux, Solaris, AIX, and Linux on System z operating systems, the file is in the$COLLATION_HOME/etc/discover-sensors/ directory.

• On Windows operating systems, the file is in the %COLLATION_HOME%\etc\discover-sensors\directory.

Use the following tags to edit the WeblogicSensor2.xml file:

<SensorPlugin xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.ibm.com/xml/schemas/taddm/FixedSensorSchema.xsd"> <name>WeblogicSensor2</name> <osgiId>com.ibm.cdb.discover.sensor.app.j2ee.weblogic2_7.1.0</osgiId>

<sensorClassName>com.collation.discover.agent.app.j2ee.WeblogicAgent2</sensorClassName> <seedClassName>com.collation.discover.seed.app.j2ee.WeblogicSeed2</seedClassName>

<resultClassName>com.collation.discover.result.app.j2ee.WeblogicServerResult2</resultClassName> <convertorClassName>com.collation.discover.engine.seedfactory.SoftwareConvertor</convertorClassName>

<defaultProfiles> <profile>Level 3 Discovery</profile> </defaultProfiles> <configuration className="com.ibm.cdb.discover.sensor.configuration.WeblogicServerAgent2Configuration"> <allowSensorToBePooledInJVM>true</allowSensorToBePooledInJVM> <domains> <item> <domainAddress> <address>DOMAIN_IP</address> <port>DOMAIN_PORT</port> </domainAddress> <addresses> <item> <address>IP_OF_FIRST_INTERFACE_ADMIN_SERVER_IS_USING</address> <port>PORT_ ADMIN_SERVER_IS_USING </port> </item> <item> <address>IP_OF_SECOND_INTERFACE_ADMIN_SERVER_IS_USING</address> <port>PORT_ ADMIN_SERVER_IS_USING </port> </item> </addresses> </item> </domains> </configuration></SensorPlugin>

You can use this configuration when the WebLogic server is using multiple interfaces on the DomainAdmin Server.

In this case, the value of DOMAIN_IP and DOMAIN_PORT is used instead ofIP_OF_FIRST_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING andIP_OF_SECOND_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING.

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

In most cases, if you have the JAR files from the current version of WebLogic, you can also discoverservers running older versions of WebLogic. When this method does not work, complete the followingsteps:

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.



1. Select Application Servers as the Component Type.2. Select Weblogic as the Vendor.3. Specify the following required information:


Ensure the WebLogic user you add to the access list has the following information:

• Administrator privileges• Password


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

com.collation.discover.agent.WeblogicSensor.UseDomainForClusterName=falseThis property is used to customize the displayName attribute for Weblogic clusters. By default,displayName is set by using WeblogicCluster name. Two Weblogic clusters can have the same name,but they can belong to different Weblogic domains. In such cases, the customization is necessary.When this property is set to true, the ObjectDisplayNameAgent recalculates the displayNameattribute for WeblogicCluster to incorporate the name of its WeblogicDomain. For example, ifWeblogicDomain is webl-dom-dr.mycompany.com:9111, and the cluster is webl_c1, thedisplayName for this cluster is webl-dom-dr.mycompany.com:9111:webl_c1.The default value of this property is false.After you change the value of the property, you must restart TADDM.

com.collation.agent.weblogic.domainsconfigurationUsed when the WebLogic server uses multiple interfaces on the Domain Admin Server(domain_ipX:domain_portX is used instead of listen_ipN:listen_portN).The syntax of the property is as follows:

com.collation.agent.weblogic.domainsconfiguration domain_ipA:domain_portA listen_ip1:listen_port1,listen_ip2: listen_port2;domain_ipB:domain_portB ...

For example:

com.collation.agent.weblogic.domainsconfiguration= 9.158.143.20:7001-9.158.143.20:7002,9.158.143.50:7001;9.158.143.20: 7001-9.158.143.20:7002,9.158.143.50:7003

com.collation.agent.weblogic.protocolsBy default, this property is disabled, and the T3 protocol is used. If you uncomment this property, youcan specify the list of protocols (separated by commas) to be used by the WebLogic sensors, as shownin 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 HTTPprotocol is used. If you want to use the HTTP protocol to connect to a WebLogic server instance, youmust enable HTTP tunneling for that instance using the WebLogic Console.

The only valid values are t3 and http. If you code an incorrect value, such as a value withtypographical errors, the WebLogic server cannot process the request properly and might stop.






Troubleshooting the sensorThis topic describes common problems that occur with the WebLogic sensor and presents solutions forthose problems.

Duplicate WebLogic domains might be createdProblem

Duplicate WebLogic domains might be created when a host of an admin server of a WebLogic domainhas many IP addresses.

Solution To remove the duplicates, make sure that the WebLogicDomainConsolidationAgent is run

after the discovery of WebLogic domains.

WebLogic sensor does not startProblem

The WebLogic sensor does not start.Solution

Perform the following actions:

• For each version of the WebLogic server, copy the JAR files from the WebLogic installation to the$COLLATION_HOME/lib/weblogic/VERSION directory. Verify the sensor configuration in the$COLLATION_HOME/etc/discover-sensors/WeblogicVersionSensor.xml file.

• Verify that the WebLogic Server port and IP address are reachable and that the WebLogic serveruses the Java Management Extensions (JMX) communication protocol that is supported by TADDM.Configure the com.collation.agent.weblogic.protocols property in the collation.properties file.

• If the WebLogic Sensor starts when using the local host address (127.0.0.1) and fails or discoversnothing, set the value of the following property in the collation.properties file to true:

com.collation.platform.os.ignoreLoopbackProcesses=true

WebLogic sensor failsProblem

The WeblogicServerVersion sensor fails.Solution

Copy the required WebLogic JAR files to the TADDM installation (see Configuring the sensor fordetails). Alternatively, the authentication information is missing or incorrect.


The following error is in the local-anchor*.log, which typically means that the WebLogic securityauthentication information is missing or incorrect:

Sensor failed in remote server:An error occurred in the null sensor.

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

Message states that nothing exists to be discoveredProblem

The WebLogic sensor runs and completes successfully with the following message:


There was nothing to be discovered.

SolutionThis message occurs when you are discovering a WebLogic Application Server. Although this situationis not a problem, ensure that the WebLogic sensor runs against the WebLogic Admin Server.

Sensor fails with WebLogic 10.xProblem

The WeblogicServerVersion sensor fails only with WebLogic 10.x.Solution

WeblogicVersionSensor uses an external command to identify the version of WebLogic. On someWebLogic 10.x installations, this command returns an unexpected empty string which causes theWeblogicVersionSensor to fail.As a workaround, use the JAR files from a WebLogic 9.x installation. WebLogic 9.x JAR files work withWebLogic 10.x.

WebLogic sensor fails to discover WebLogic Administration ServerProblem

While attempting discovery of a WebLogic Administration Server, the WebLogic sensor fails as a resultof a non-functioning DNS.

SolutionDiscoveries involving the sensors related to WebLogic Administration Servers must have working DNS.As a workaround, change com.collation.platform.os.disableRemoteHostDNSLookups totrue, and ensure that the TADDM server always has the correct DNS search path.

WebLogic sensor fails due to timeoutProblem

The WebLogic sensor fails due to timeout.Solution

Increase value of the com.collation.discover.agent.NAME timeout property in thecollation.properties file, where NAME represents the name of the sensor that is configured inthe XML file in the $COLLATION_HOME/etc/discover-sensors directory. The following examplesshow how to code this property:

com.collation.discover.agent.WeblogicSensor2.timeout=7200000com.collation.discover.agent.WeblogicSensor.timeout=7200000

WebLogic sensor fails after migrationProblem

The WebLogic sensor fails after migration.Solution

Ensure that you run the $COLLATION_HOME/bin/template-upgrade.sh script.

Sensor fails due to T3 problemProblem

The WeblogicServerVersion sensor fails due to inaccessible T3 protocol.Solution

In some installations, the T3 protocol might be blocked. In this case, configure the WebLogic Serversto use the http protocol, and configure the WeblogicSensors to use http as well.For example:


com.collation.agent.weblogic.protocols=t3,http

WeblogicServerVersion fails due to timeout when issuing a version commandProblem

The weblogicServerVersion times out while issuing the version command. The problem can be due tothe port being blocked by the firewall. The following example shows port number 6079 is blocked by afirewall:

2009-09-09 12:29:38,802 DiscoverManagerDiscoverWorker-11 WeblogicServerVersionSensor-169.70.70.100-6079 DEBUGj2ee.WeblogicServerVersionAgent - Executing command: -cp/opt/IBM/taddm/dist/lib/weblogic/10.0/weblogic.jar:/opt/IBM/taddm/dist/lib/weblogic/10.0/webservices.jar:/opt/IBM/taddm/dist/lib/weblogic/10.0/wljmxclient.jar -Duser.language=en -Duser.region=US weblogic.Admin -urlt3://169.70.70.100:6079 -username confadmin -password XXX VERSION 2009-09-0912:29:39,133 DiscoverManager DiscoverWorker-11WeblogicServerVersionSensor-169.70.70.100-6079 DEBUG util.OsCommand - Commandexecuted, capturing output 2009-09-09 12:33:03,526 DiscoverManagerDISCOVER_SENSOR_CLEANUP_DiscoverWorker-11WeblogicServerVersionSensor-169.70.70.100-6079 DEBUGj2ee.WeblogicServerVersionAgent - JavaCommand errorjava.lang.InterruptedException at java.lang.Object.wait(Native Method) atjava.lang.Object.wait(Object.java:231) at java.lang.Thread.join(Thread.java:680)at com.collation.platform.util.OsCommand.execute(OsCommand.java:411)

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

Some JDBC dependencies are not created between a WebLogic server and databaseserversProblem

TADDM discovers both the WebLogic server and a related database server but does not create arelation between them. Such a relation is based on the JDBC connection properties that are definedon the application server.

Solution


• The dependencies are created by the JDBCDependencyAgent that runs in the Dependency topologyagent group. Ensure that the agent is run after the discovery of the WebLogic servers.

• The JDBCDependencyAgent processes only the recently discovered application servers. If somedependencies are still missing after the agent has run, rediscover the WebLogic servers, and wait forthe topology agents to run again.

• Ensure that the database server is one of those that supports the creation of transactionaldependencies between it and the WebLogic application server. The following databases aresupported:


WebLogic sensor fails with error- "java.lang.OutOfMemoryError: Java heap space"


ProblemIf a target machine has multiple WebLogic Servers running on different virtual IPs, TADDM might begiven OutOfMemory error on running WebLogic sensors. The reason might be with WebLogic Sensorsseeds which contains all the process list running on the system.Some WebLogic process might have thousands of BindAddress and LogicalConnection objectsresulting in the seed object occupying significant memory. If many WebLogic sensors are invoked,they create their separate copy of process list having the same data, resulting in increased memoryconsumption for the same data.

SolutionYou can share the process list of same targets between seeds of different WebLogic sensors whichhelps in reducing the memory requirement by enabling the following properties in thecollation.properties file:

com.collation.discover.WeblogicApplicationSeed.processlist.shared=true

com.collation.discover.WeblogicDomainSeed.processlist.shared=true

com.collation.discover.WeblogicLauncherSeed.processlist.shared=true

com.collation.discover.WeblogicServerSeed.processlist.shared=true

Their default value is false.

Weblogic over merging issue occurred due to wrong listenPort set by sensor inBindAddress

ProblemIf SSL is enabled but the sslPort is not configured, by default it is set as 7002 by the sensor.If the sslPort value is greater than listenPort value, listenPort value is set in BindAddress. Otherwise,the default sslPort value is set in BindAddress.By default, the sslPort value is always less than the listenPort value due to which, this default value ofsslPort (7002) is always set in BindAddress. This leads to overmerging.

SolutionTo set correct listenPort of Weblogic in BindAddress, you must configure a collation to resolve thisconflict :

com.ibm.cdb.discover.app.j2ee.weblogic.util.WeblogicUtilsModelObject.setBindPortToListenPort=true

The default value is false.The possible values are true and false.

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

Sensor name that is used in the GUI and logs• WeblogicLauncherSensor• WeblogicApplicationSensor• WeblogicDomainSensor


• WeblogicServerSensor

Security issuesThe WebLogic pluggable sensors require computer system credentials or WebLogic credentials.

LimitationsFor a discovery to run, the WebLogic pluggable sensors must have access to the domain configurationfiles. The location of the domain configuration directory can be determined by the sensor in the followingspecific situations:

• The WebLogic server is started as a Windows service.• 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

• The WebLogic server is started as a Windows or UNIX process, and it is started with the followingargument:

-Dweblogic.RootDirectory=domain_directory

• The WebLogic server is started as a UNIX process, and the location of the domain configurationdirectory is set as one of the following process environment variables:

– DOMAIN_HOME– LONG_DOMAIN_HOME– PWD– OLD_PWD– OLDPWD

• The WebLogic server is started as a Windows or UNIX process, and the process contains a variable withthe 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 subdirectories 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 aresearched for the config_file_name:

– /home/weblogic/bea/my_user_projects/domains/domain92/– /home/weblogic/bea/my_user_projects/domains/domain92/config/

• The WebLogic server is started as a Windows or UNIX process, and the process contains a variable withthe path to the servers subdirectory. The servers directory is located in the Domain home directory. Asearch for the configuration file is carried out in the directory and all sub directories defined in the pathfor 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/

• The WebLogic server is started as a Windows or UNIX process, and the process contains a variable withthe path to the user_project subdirectory. The user_projects directory is the default directorycontaining WebLogic projects. A search for the configuration file is carried out in the directory and allsub 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/

• The WebLogic launcher sensor configuration contains the following information:

– The domain configuration directory.– The IP address on which the WebLogic administration console is listening.– The port number on which the WebLogic administration console is listening.

For details, see “Configuring the sensor” on page 164.

On Windows, the WebLogic launcher sensor normally does not start if the WebLogic process is not startedas 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 configurationinformation in the WebLogic launcher sensor configuration file.

For the WebLogic managed server, the WebLogic process name must be called with the followingargument:

-Dweblogic.management.server=server_name

The WebLogic SSH pluggable sensors must not be run with the WebLogic sensor in the same discovery, soyou must not enable the WebLogic SSH pluggable sensors and the WebLogic sensor in the same discoveryprofile.


• app.AppConfig• app.AppServer• app.ConfigFile• app.j2ee.weblogic.WebLogicServer• app.j2ee.J2EEComponent• app.j2ee.J2EEDeployedObject• 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• app.j2ee.weblogic.WebLogicSSLSettings• app.j2ee.weblogic.WebLogicServer• app.j2ee.weblogic.WebLogicServlet• app.j2ee.weblogic.WebLogicVirtualHost• app.j2ee.weblogic.WebLogicWebContainer• app.j2ee.weblogic.WebLogicWebModule• app.ProcessPool• app.SoftwareContainer• app.web.WebVirtualHost

Resources that the sensor discoversThis topic describes the resources that can be discovered by the WebLogic pluggable sensors, and howthose discoveries work.

Information is gathered from XML configuration files on the target machine. WebLogic default propertiesare stored in an XSD schema, rather than XML configuration files.

WebLogic launcher sensorThe WebLogic launcher sensor is started, after the generic server sensor, using a pluggable template,configured in plugin.xml. It discovers most typical WebLogic installations, and can be manuallyconfigured if necessary.

It discovers the following information:

• The path to the directory containing configuration files for the domain.• The version of WebLogic installed on the target machine.• Whether the target is an administration server or a managed server.• The listen IP and port of the administration server.• Basic information about the structure of the WebLogic domain and servers.

The WebLogic launcher sensor creates the following objects:

• The WebLogic domain model object with only the attributes that are included in the naming rule.• The WebLogic server model objects with only the attributes that are included in the naming rule.

The WebLogic launcher sensor starts the following sensors:

• WebLogic domain sensor for administration server• WebLogic server sensor for administration server

WebLogic domain sensorThe WebLogic domain sensor discovers information about the full WebLogic domain.

The following information (available in XML configuration files), is discovered:

• Domain details• Machine details• Cluster details


• SSL settings• JTA• JDBC connection pool• JDBC data source• JDBC multi pool• JMS server• Node manager settings

The WebLogic domain sensor creates the WebLogic domain object.

WebLogic server sensorThe WebLogic server sensor discovers information about the full WebLogic server and basic informationabout the WebLogic domain.

The following information (available in XML configuration files), is discovered:

• Server details• JDBC connection pool• JDBC data source• JDBC multi pool• JMS server

The WebLogic server sensor creates the WebLogic server model object.

The WebLogic server sensor starts the WebLogic application sensor.

WebLogic application sensorThe WebLogic application sensor discovers the WebLogic applications deployed on the WebLogic serverand the WebLogic applications deployed on the WebLogic domain.

The following information about the deployment is stored:

• Application or module, for example, J2EEApplication, EJBModule, WebModule, or ConnectorModule.• Application or module details, including J2EEDeployedObjects, for example WebLogicEntityEJB,

WebLogicServlet, and WebLogicConnector.• Application subdeployment information.

Asynchronous and script-based discovery supportThe WebLogic SSH sensor supports asynchronous and script-based discovery.



The following sensors, which are descendants of the WeblogicLauncherSensor sensor, require noconfiguration:

• WeblogicApplicationSensor• WeblogicDomainSensor• WeblogicServerSensor


LimitationsThe last modification dates of collected configuration files are not available.


Configuring the sensorThe WebLogic pluggable sensors can be configured by editing the plugin.xml configuration file.

You can perform WebLogic-specific configuration by editing the <configuration> element for thefollowing WebLogic pluggable sensors:

• WebLogic launcher sensor• WebLogic server sensor• WebLogic application sensor

WebLogic launcher sensor configurationThe plugin.xml file for the WebLogic launcher sensor is located in the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.app.j2ee.weblogic.sensor.weblogiclaunchersensor_1.2.0directory.

Within the <configuration> element, you can configure information about the configuration directoryfor each domain. Place the information for each domain in a separate <item> element. For each domain,you can configure the following elements:

<configDirectory>The domain configuration directory.

<adminServer>Contains information about the IP address and port number on which the WebLogic administrationconsole 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, andits 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 serverwith the following argument:

-Dpredefined.domain.config.dir=domain_directory


WebLogic server sensor configurationThe plugin.xml file for the WebLogic server sensor is located in the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.app.j2ee.weblogic.sensor.weblogicserversensor_1.2.0directory.

In the plugin.xml configuration file, you can configure the following elements:

<discoverAppDescriptors>Specifies if the discovery of application descriptors is enabled. The discovery of applicationdescriptors can be time consuming because the descriptors are defined in additional configurationfiles on the remote machine where WebLogic is installed.

<discoverJdbcDetails>Specifies if the discovery of JDBC descriptors is enabled. The discovery of JDBC descriptors can betime consuming because the descriptors are defined in additional configuration files on the remotemachine where WebLogic is installed.

The following sample configuration file displays the typical usage of the <discoverAppDescriptors>and <discoverJdbcDetails> elements:

<configurationclassName="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicServerConfigurationItem"> <discoverAppDescriptors>true</discoverAppDescriptors> <discoverJdbcDetails>true</discoverJdbcDetails></configuration>

WebLogic application sensor configurationThe plugin.xml file for the WebLogic application sensor is located in the following directory:

$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.app.j2ee.weblogic.sensor.weblogicapplicationsensor_1.2.0

In the plugin.xml configuration file, you can configure the following elements:

<discoverApplicationDetails>Specifies if the discovery of application/module details is enabled. The discovery of application/module descriptors (J2EE descriptors) can be time consuming because the descriptors are defined inadditional configuration files on the remote machine where WebLogic is installed.

The following sample configuration file displays the typical usage of the<discoverApplicationDetails> element:

<configurationclassName="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicApplicationConfigurationItem"> <discoverApplicationDetails>true</discoverApplicationDetails></configuration>

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

com.collation.discover.agent.WeblogicSensor.UseDomainForClusterName=falseThis property is used to customize the displayName attribute for Weblogic clusters. By default,displayName is set by using WeblogicCluster name. Two Weblogic clusters can have the same name,but they can belong to different Weblogic domains. In such cases, the customization is necessary.When this property is set to true, the ObjectDisplayNameAgent recalculates the displayNameattribute for WeblogicCluster to incorporate the name of its WeblogicDomain. For example, ifWeblogicDomain is webl-dom-dr.mycompany.com:9111, and the cluster is webl_c1, thedisplayName for this cluster is webl-dom-dr.mycompany.com:9111:webl_c1.The default value of this property is false.After you change the value of the property, you must restart TADDM.


Troubleshooting the sensorThis topic describes common problems that occur with the WebLogic SSH sensor and presents solutionsfor those problems.

Duplicate WebLogic domains might be createdProblem

Duplicate WebLogic domains might be created when a host of an admin server of a WebLogic domainhas many IP addresses.

Solution To remove the duplicates, make sure that the WebLogicDomainConsolidationAgent is run

after the discovery of WebLogic domains.

The sensor fails with a Domain config dir not found errorProblem

The Domain configuration directory cannot be found. Check the ps output for the process and verify inthe limitations section that the configuration is supported.

SolutionUse one of the following methods:

• Run the WebLogic server using the argument -Dpredefined.domain.config.dir=domain_directory or –Dweblogic.RootDirectory=domain_directory

• Configure the path to the domain administrator server in the WebLogic launcher sensorconfiguration. For details, see “Configuring the sensor” on page 164.

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

WeblogicLauncherSensor fails when trying to discover WebLogic on HP-UX and the following errormessage can be found in the sensor log file: "Cannot find server name in command line: <COMMANDLINE>". A possible reason of this failure is the cut of a ps command output, which is a documentedbehavior of HP-UX.

Solution

1. Set com.ibm.cdb.discover.WeblogicLauncherSensor.parseConfigXml=true incollation.properties.

2. Restart TADDM and run the discovery again.

If extracting the server name from the command line fails, WeblogicLauncherSensor reads it from thelocal configuration file (config.xml).

Some JDBC dependencies are not created between a WebLogic server and databaseserversProblem

TADDM discovers both the WebLogic server and a related database server but does not create arelation between them. Such a relation is based on the JDBC connection properties that are definedon the application server.

Solution


• The dependencies are created by the JDBCDependencyAgent that runs in the Dependency topologyagent group. Ensure that the agent is run after the discovery of the WebLogic servers.


• The JDBCDependencyAgent processes only the recently discovered application servers. If somedependencies are still missing after the agent has run, rediscover the WebLogic servers, and wait forthe topology agents to run again.

• Ensure that the database server is one of those that supports the creation of transactionaldependencies between it and the WebLogic application server. The following databases aresupported:


Cloud sensor

AWS sensorThe AWS Sensor first discovers EC2 and S3 service component information from public cloud AWSenvironments, which then facilitates a comprehensive detailed discovery seamlessly for the discoveredEC2 components and related information. This is currently designed as a non-scripted sensor.

Sensor name that is used in the GUI and logsAwsSensor

Elements discovered by the sensorThe sensor discovers the following elements:

• Aws• AwsS3Bucket• AwsS3BucketContent• ComputerSystem (EC2 Instances)

In the Discovery Management Console and Data Management Portal, a Clouds Component Type isrepresented by a white-colored Cloud design icon and AWS using an orange-colored cubed icon.

The AwsSensor interacts with AWS environment through web interface for retrieving the high-levelmanagement information for the hosted EC2 and S3 services. The retrieved data primarily comprises ofattribute data that is required to match naming rules and create valid model objects.

PrerequisitesFollowing are the prerequisites of AWS:

• AWS public URL is accessible from TADDM discovery server• Ensure that AWS account login and EC2 instance credentials are correctly configured in TADDM Access

List. For details, see “Configuring the access list” section• EC2 instances are configured in AWS environment• EC2 instances/VMs are accessible from TADDM discovery server for detailed (or, deep) discovery to

successfully fetch the details• Sensor-specific prerequisites (if any, related to ports, permissions, etc.) must be met for detailed (or,

deep) discovery to work seamlessly for EC2 instances• S3 Buckets are configured in AWS environment


Connection to AWS EnvironmentThe AWS Sensor connects securely (using https) to the public cloud AWS environment using thecredentials provided for AWS Account. For details, see “Configuring the access list” section. In case anyproxy configurations are required for access, these need to be properly configured in the sensorproperties. For details, see “Configuring the discovery profile” section.

Model objects with associated attributesThe AWS sensor creates model objects with associated attributes. The attributes indicate the type ofinformation that the sensor collects about public cloud AWS environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name:

com.collation.platform.model.topology.cloud.aws.Aws

• Endpoint• Identity• AuthName• Name• GroupMembers (Ec2Instances)• GroupMembers (Ec2Instances)• XA

– TotalVmInstances

com.collation.platform.model.topology.cloud.aws.AwsS3Bucket

• Name• LastStoredTime• AwsS3BucketContent

com.collation.platform.model.topology.cloud.aws.AwsS3BucketContent

• Name• URI• ContentType• Size• LastModifiedTime

com.collation.platform.model.topology.sys.ComputerSystem (corresponding to EC2 instances)

• AwsInstanceId• Name• Type• Description• IpInterfaces• OSRunning• CPU• StorageExtent• MemorySize• VirtualMachineState


Configuring the sensorBefore using the AWS sensor, you must configure it.

Configuring the discovery scope

AWS sensor is designed to support discovery using URL (introduced NEW) in Discovery Scope. This isin-line with the fact that public AWS account console is accessible via URL. Create an AWS discoveryscope with the URL corresponding to the geographical locale of the AWS account/environment andensure that the configured URL is accessible from TADDM discovery server.To configure the discovery scope, complete the following steps:

1. In the Discovery drawer of the Discovery Management Console, click Scope.2. In the Scope/Scope Set window, click Add.3. In the Add Scope window, select include as “Url” and specify the Fully Qualified Domain Name

with appropriate description (if any).4. Click Ok to save this configuration.

For example URL for AWS account hosted in Singapore region is as below:https://ap-southeast-1.amazonaws.comFor more details, please refer: https://docs.aws.amazon.com/general/latest/gr/rande.html

Configuring the access list

AWS Sensor requires separate provisioning of access-list entries corresponding to AWS account andAWS EC2 instances.AwsAccount

1. In the Discovery drawer of the Discovery Management Console, click Access List.2. In the Access List window, click Add3. Select Cloud as the Component Type.4. Select Aws as the Vendor.5. Specify the following required information:

a. Access Key Id (User name)

b. Secret Access Key (Password)

You must be authorized to login to the AWS account.

Note: A “Component Type” of 'Cloud' and “Vendor” type as “OtherClouds” is placed as anextension template for future cloud sensors. Currently, it is not in use.

EC2 InstancesConnection to EC2 instance is required during detailed (or, deep) discovery. Two scenarios mentionedbelow are possible:

1. In case VM/EC2 instance (Linux, or, Windows) permits password based authentication mechanism,then the corresponding Access List entry with Component Type as Computer System, or, ComputerSystem (Windows) must be added as usual in the access-list.

2. In case VM/EC2 instance (Linux) permits login through secure PEM file:

a. In the Discovery drawer of the Discovery Management Console, click Access List

b. In the Access List window, click Add

c. Select Computer System as the Component Type

d. Specify the following required information:

• User name• Password (leave this field empty)


https://ap-southeast-1.amazonaws.com

https://docs.aws.amazon.com/general/latest/gr/rande.html

Note: PEM files corresponding to EC2 instances must be placed manually at appropriate path onTADDM (and, Anchor) discovery server as configured in TADDM collation.properties file. For details,see “Configuring the collation.properties file entries”.

Configuring the collation.properties file entries

This topic lists the collation.properties file entries that the sensor uses.The sensor uses the following entries in the collation.properties file:

com.ibm.cdb.security.auth.pemFilesPath.linux=/home/taddmusr/pemFiles/

This property mentions the path on Linux TADDM (and, Anchor) discovery server where all the PEMfiles are placed.

com.ibm.cdb.security.auth.pemFilesPath.windows=%windir%\\temp\\pemFiles\\

This property mentions the path on Windows TADDM (and, Anchor) discovery server where all thePEM files are placed.

Key points to be noted here:

1. Both the above properties are user-configurable and must be set per customer environments.2. The PEM files must be placed manually at the specified paths.3. Sufficient file and user permissions must be granted to above mentioned directories, to prevent

any permission related issues during session establishment in detailed discovery

a. Folder permissions: 775 (taddmusr:taddmusr)

b. PEM file permissions: 644 (taddmusr:taddmusr)

com.collation.aws.proxy.password=PASSWORD1

This property is used to configure password in plain-text for the proxy user configured in sensorconfiguration.

1. Login to the TADDM discovery server.2. Run either the encryptprops.sh file, or, the encryptprops.bat file (located in the

$COLLATION_HOME/bin directory). This script encrypts the plain-text password.

com.collation.discover.agent.sys.ComputerSystem.FindAwsInstanceId=false

This property must be set to true while using AWS sensor and discovering EC2 targets. This enablesTADDM to execute command for retrieving AWS Instance Id on EC2 target while runningComputerSystem Sensors (e.g. LinuxComputerSystemSensor, WindowsComputerSystemSensor etc.).In case user is not discovering EC2 targets, it is recommended to set this value to false to preventsuch redundant command execution on non-EC2 targets. The default value of this property is false.

Configuring the discovery profile

By default, the AWS Sensor is enabled for a Level 2 and Level 3 discovery. The sensor discoversinformation configured using EC2, or, S3 services and then triggers the 2nd level or deep discoverycorresponding to EC2 instances. To disable 2nd level discovery, or, modify other configurationsettings, create a discovery profile for the AWS sensor, and customize the sensor settings.To create the discovery profile, complete the following steps:

1. In the Discovery drawer of the Discovery Management Console, click Discovery Profiles.2. In the Discovery Profiles window, click New.3. In the 'Create New Profile' window, type the profile name and description. From the 'Clone existing

profile list', select Level 3 Discovery and click OK.4. On the Sensor Configuration tab, select the AwsSensor sensor and click New.


5. In the Create Configuration window, type the name and description for your configuration andselect the Enable Configuration check box.

6. In the Configuration section of the Create Configuration window, clickenableSecondLevelDiscovery. Double-click the Value field in the row, and type false.

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

Properties

You can modify the following properties and attributes:

proxyIp

It refers to proxy IP Address (in case required) to access AWS public URL from TADDM server.

proxyPort

It refers to proxy port ((in case, proxyIp is configured).

proxyTimeout

It refers to proxy timeout values in milliseconds ((in case, proxyIp is configured).

proxyType

It refers to proxy type (permissible values: HTTP, or, HTTPS) to access AWS public URL fromTADDM server.

The default value is HTTPS.

proxyUser

It refers to proxy username (in case, proxyIp is configured).

Configuring the gateway

As required otherwise, discovery of Windows machines in public cloud AWS environment can be easilydone by configuring Gateways (hosted in AWS environment). Following steps are involved:

1. Configure a Gateway machine. Refer URL:https://www.ibm.com/support/knowledgecenter/en/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/UserGuide/c_cmdb_anchorsandgateways.html for moredetails.

2. TADDM

a. Ensure that the Gateway machine must be added to the “Discovery>Anchors and Gateways”section of the discovery management console.

b. Access credentials for windows gateway and windows EC2 instances must be provisioned in theTADDM access list details.

3. AWS

Configure “Security Group” with the below mentioned “Inbound Rules” for:

Table 15. Windows Gateway

Type Protocol Port Range Source

SSH TCP 22 TADDM

Custom TCP TCP 135 TADDM

Table 16. Target (EC2 instance)


Custom TCP TCP 135 Windows Gateway


https://www.ibm.com/support/knowledgecenter/en/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/UserGuide/c_cmdb_anchorsandgateways.html


Table 16. Target (EC2 instance) (continued)


Custom TCP TCP 49152 – 65535 Windows Gateway

Custom TCP TCP 49152 – 65535 TADDM

Configuring the Anchor

As required otherwise, discovery behind the AWS firewall can be easily done by deploying anchors(hosted in AWS environment). Following steps are involved:

1. Configure an Anchor machine. Refer URL: https://www.ibm.com/support/knowledgecenter/en/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/UserGuide/c_cmdb_anchorsandgateways.html

2. TADDM

a. Ensure that the Anchor machine must be added to the “Discovery > Anchors and Gateways”section of the TADDM discovery management console.

• Since the deployed Anchor will be specific to public AWS environment, it is highly recommended thatduring configuration the Anchor must be attached to relevant AWS discovery scope using the scope-set, or, scope-group limiting feature

• Moreover, the Anchor configured in the above point must not be configured in AWS discovery scope

b. “sudo” privileges need to be provided for “lsof” command. This is done by updating the followingline in ‘collation.properties’ file as below:

com.collation.discover.agent.command.lsof.Linux=sudo lsof

c. Manually place the PEM files on Anchor server. For details, see “Configuring the collation.propertiesfile entries” section.

3. AWS

a. Configure a “Security Group” with the below mentioned “Inbound Rules”:

Table 17. Anchor


SSH TCP 22 TADDM

Custom TCP TCP 8497 TADDM

Table 18. Target (EC2 instance)


SSH TCP 22 Anchor

b. In case a Windows Gateway is configured beyond an Anchor, refer details in “Configure theGateway” section.

Troubleshooting the sensorThis topic describes common problems that occur with the AWS sensor and presents solutions for thoseproblems.

The sensor fails with description 'CTJTD1595E Error – No AWS credentials configured in TADDMAccess List'

ProblemNo AWS account credentials may be configured in the TADDM Access List.




SolutionValidate on TADDM Discovery Management Console UI in “Discovery > Access List” whether any AWSspecific credentials have been configured or not.

The sensor fails with description 'CTJTD1596E Error – No AWS account discovered, please verifysensor configuration'

ProblemThe problem may occur because of some erroneous configuration while executing AWS sensor.

SolutionValidate the configuration settings for AWS sensor on TADDM Discovery Management console UI. Thesettings may be related to:

• URL correctness• Access list credential correctness• AWS Sensor configuration properties• Network connectivity issue (public AWS URL may not be reachable from TADDM server)

Anchor sensor fails with description 'CTJTD0060E The discover operation for the anchor sensor isunable to find or create an anchor: CTJTD2072E An error occurred. The server cannot install the JavaSDK on the remote host. CTJTD2231E The file is not copied. CTJTP1127E The copy command fails forthe following target: java.io.IOException: InputStreamPipe closed'.

ProblemThe problem may occur because of timeout happening while trying to copy file to remote anchorserver.

SolutionValidate for any network connectivity issues between TADDM discovery server and the remote Anchorserver.If file transfer was ongoing and the timeout occurs due to large file size, try changing the default valueof 360000 minutes to a higher value (say, 1500000) for below property in collation.properties file:

com.collation.SshSessionCopyTimeout=360000

Restart TADDM process once the property value is updated.

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

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

Sensor name that is used in the GUI and logsDb2Sensor and Db2WindowsSensor

PrerequisitesThe sensor assumes the following prerequisites:

• Discovery of the computer system must succeed.• DB2 must be installed in the instance owner's home directory.

Security issuesThe DB2 user credentials must belong to the DB2 administration group.


Discovery is performed by using shell scripts that run the following DB2 commands:

db2Command line processor invocation command

db2ilistList instances command

db2setDB2 profile registry command

db2licmLicense management tool command

db2levelShow DB2 service level command

db2get dbm cfg

LimitationsIncorrect characters can be discovered if you are using a 32-bit DB2 on a 64-bit Windows operatingsystem. 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.

If more than one version of DB2 is installed on the same Windows computer system, the sensor cannotdiscover the IBM DB2 Universal Database (UDB) server.

TADDM runs the topology building process on a periodic basis. Until the topology building process hascompleted after a discovery, the database names that are displayed for remote systems might not beunique. After the topology build process has completed, the database name contains both the portnumber and the IP address of the remote database.


• app.db.db2.Db2AdminServer• app.db.db2.Db2Alias• app.db.db2.Db2BufferPool• app.db.db2.Db2ConfigValue• app.db.db2.Db2Container• app.db.db2.Db2Database• app.db.db2.Db2DatabaseConfigValue• app.db.db2.Db2Instance• app.db.db2.Db2InstanceConfigValue• app.db.db2.Db2Module• app.db.db2.Db2Schema• app.db.db2.Db2Server• app.db.db2.Db2ServerProcess• app.db.db2.Db2System• app.db.db2.Db2SystemConfigValue• app.db.db2.Db2TableSpace


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




• For script-based discovery, the sensor requires database credentials. If these credentials are notprovided, the sensor completes with the following error:

No system detected

• Discovery of application descriptors is not supported.




1. Select Database as the Component Type.2. Select DB2 as the Vendor.3. Specify the following required information:


The DB2 UNIX sensor uses credentials from the access list in the following sequence:

1. The sensor searches the access list looking for the DB2 user credentials.

This is the owner of the current DB2 instance.2. If step 1 fails, the sensor attempts to connect to DB2 using each DB2 user credential from the access

list.3. If step 2 fails, the sensor attempts to connect using the Computer System user credentials (using user

credentials from the Computer System access list).

For discovery of multiple DB2 installations on a single machine: DB2, the user credentials from the accesslist must belong to the DB2 administration group for all DB2 installations.

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

The DB2 sensor that is running on a Windows system (Db2WindowsSensor) uses the following property:com.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout =300000

The default value is 300000. The value must be an integer.

This property specifies the maximum amount of time (in milliseconds) that the DB2 sensor can run thedb2dfind command on a Windows system.

To be effective, the value of this property should be:


• Greater than the value of the com.collation.SshSessionCommandTimeout property, whichcontrols the time that is allowed for the SSH command to run on the Windows gateway. If the valueof the Db2WindowsAgent.sshSessionCommandTimeout property is less than the value of thecom.collation.SshSessionCommandTimout property, thecom.collation.SshSessionCommandTimout value is used.

• Less than the value of the com.collation.discover.agent.Db2Sensor.timeout property(or com.collation.discover.DefaultAgentTimeout if the DB2-specific timeout is not set).Because the sensor can stop before it finishes collecting information, the value of the Db2Sensortimeout property should be greater than thecom.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout property.

If needed, you can change the values of the com.collation.SshSessionCommandTimeout andcom.collation.discover.agent.Db2Sensor.timeout properties. Thecom.collation.discover.agent.Db2Sensor.timeout property is specific to the DB2 sensor,and overrides the value of the com.collation.discover.DefaultAgentTimeout property.

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=sudoThis value enables access to the db2find.sh script executed during the discovery using the sudocommand.

com.collation.discover.agent.DB2Agent.db2findschemascript=sudoThis value enables access to the db2findschema.sh script executed during the discovery using thesudo command.

com.collation.discover.agent.DB2Agent.systemcommand=sudoThis value enables access to the system command executed during the discovery using the sudocommand.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM DB2 sensor and presents solutions forthose problems.

The DB2 sensor fails during discoveryProblem

The DB2 sensor is timing out during the discovery run.Solution

Increase the com.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout property in the collation.properties file. Also, you could increase thecom.collation.discover.agent.Db2Sensor.timeout property to ensure that it is always larger than thecom.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout property.

Dependencies exist between a database and a business application but are notdetectedProblem

Although dependencies exist between a database and a business application, no dependency isdetected because the user that is defined in the discovery access list for DB2 is not the instanceowner.

SolutionFor discovery processes to find the DB2 commands to list databases, the user that is defined in thediscovery access list for DB2 must source the DB2 profile in the user profile.


The Details panel for a discovered DB2 component is blankProblem

When performing a discovery, the Details panel under the License tab for a discovered DB2component is blank. This problem affects all levels of TADDM, on all platforms.

SolutionOn UNIX and Linux, the db2licm executable routine must have the proper permissions for the userspecified in the Discovery Management Console as connecting to the database. To retrieve the licenseinformation, the Discovery user must also have the primary group of the DB2 instance owner in itsgroup list.

CTJTP1127E The copy command fails during a DB2 discoveryProblem

The following error message is displayed in the Discovery Management Console during a discovery ofDB2:

CTJDT0234E The following error occurred:CTJDT0235E The following erroroccurred when running the DB2 discovery script (db2find.sh): sh coll/bin/db2-db2find.sh.

Additionally, the following information is displayed in the DB2 sensor log:

com.collation.discover.agent.AgentException: CTJDT0235E The following erroroccurred when running the DB2 discovery script (db2find.sh): sh coll/bin/db2-db2find.sh.at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.runDb2Find(Db2Sensor.java:414)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.findSystems(Db2Sensor.java:275)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.discover(Db2Sensor.java:212)at com.collation.discover.engine.AgentRunner.run(AgentRunner.java:131)at com.collation.discover.engine.DiscoverEngine.processWorkItem(DiscoverEngine.java:1247)at com.collation.discover.engine.DiscoverEngine$DiscoverWorker.run(DiscoverEngine.java:816)Caused by:com.collation.platform.session.SessionClientException: CTJTP1127E The copy command failed for java.io.EOFException: SSHSCP1: premature EOF.at com.collation.platform.session.Ssh2SessionClient.copyToRemote(Ssh2SessionClient.java:441)at com.collation.platform.session.Ssh2SessionClient.copyToRemote(Ssh2SessionClient.java:397)at com.collation.platform.session.SessionClientPool.copyToRemote(SessionClientPool.java:236)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.prepareScript(Db2Sensor.java:726)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.runDb2Find(Db2Sensor.java:383)... 5 more

SolutionThis error message appears because the secure copy (scp) command is not in the PATH of the user IDthat 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 theremote computer system that is being discovered. Define the <taddmusr> PATH environment variablein this file. Make sure that you include the full path to the scp command in the PATH environmentvariable.

The DB2 sensor fails with error CTJTD0234EProblem

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


SolutionThis message is displayed because the PATH variable does not include the DB2 commands needed bythe db2find.sh script.

To correct this problem, add the required paths to the following entry in thecollation.properties file:

com.collation.discover.agent.path.system_uname

If the problem still exists, you can run the sensor scripts via sudo, for which you must have access tosuch commands as db2licm and db2set. To run the script via sudo, use the following property:

com.collation.discover.agent.DB2Agent.db2findscript.1.2.3.4=sudocom.collation.discover.agent.DB2Agent.db2findschemascript.1.2.3.4=sudocom.collation.discover.agent.DB2Agent.systemcommand1.2.3.4=sudo

Warning occurs during a DB2 sensor script-based discoveryProblem

During the script-based discovery, the following warning message is displayed:

CTJTD1006E Invalid data in output file in section: db2findschema

SolutionVerify that the DB2 user credentials (owners of all the DB2 instances) are added to the access list. Ifthe problem still exists, verify that the db2ilist command is working correctly on the discoveredsystems. For information about this command, see the technote that is titled "DB2ilist does not returnthe instance" at: https://www.ibm.com/support/docview.wss?uid=swg21420898.

The discovery of DB2 that runs on a non-English-language system failsProblem

When you want to discover non-English-language targets, for example Japanese DB2 servers, thediscovery fails. The log files contain the following message:

2016-06-08 21:27:49,778 DiscoverManager [DiscoverWorker-3]2016060821265731#Db2Sensor-37.53.105.24-60012 DEBUGsession.SessionClientPool - PoolEncoding=IBM-943 ClientEncoding=IBM-943

Additionally, the output of the db2find command contains question marks, for example ?gp?:db2set -g, instead of the tilde characters, for example ~gp~: db2set -g.

SolutionThe cause of the issue is that the encoding on your discovery targets is different than on the TADDMserver. To solve the issue, add the following property to the collation.properties file:

com.collation.platform.session.EncodingOverRide=UTF-8

For details, see the Discovery properties topic in the TADDM Administrator's Guide.

IBM Informix sensorThe IBM Informix sensor discovers IBM Informix Dynamic Servers.

Sensor name that is used in the GUI and logsInformix

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


https://www.ibm.com/support/docview.wss?uid=swg21420898

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

Model objects with associated attributesThe IBM Informix sensor creates model objects with associated attributes. The attributes indicate thetype of information that the sensor collects about IBM Informix Dynamic Server resources in your ITenvironment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.app.db.ids.IDSAlias

• AliasName• Parent• Protocol• ServiceName

app.db.ids.IDSBufferPool

• BufferPoolID• NumBuffers• Size

app.db.ids.IDSChunk

• ChunkNumber• FreeSpace• Offset• Size• MirrorOffset• Parent

app.db.ids.IDSConfigValue

• ConfigID• ConfigName• DefaultValue• EffectiveValue• OriginalValue

app.db.ids.IDSDatabase

• DatabaseLocale• LoggingType• Name

app.db.ids.IDSInstance

• BitSize• ConnectOption• Home• Host• Name• ProductName


• ProductVersion• OnConfig• Protocol• SQLHostFile• Status• VersionString

app.db.ids.IDSSegment

• OS_SHM_ADDR• OS_SHM_ID• OS_SHM_KEY• SegmentClass• Size

app.db.ids.IDSServerProcess

• OSProcessName• PID• VpClass• VpID

app.db.ids.IDSSpace

• Chunks• ObjectType• PageSize• SpaceName• SpaceNumber

app.db.ids.IDSStartupEnvironmentVar

• StartupEnvVarName• StartupEnvVarValue

Configuring the access listTo give the IBM Informix sensor access to the Informix Dynamic Server, you must configure the accesslist.


1. From the Discovery Management Console, create a discovery scope set that contains the IP address ofthe Informix Dynamic Server.

2. To create an access list, click the Access List icon.3. In the Access List window, click Add.4. In the Component Type field of the Access Details window, click ComputerSystem.5. Type the credentials to access the target Informix Dynamic Server. TADDM uses JDBC to connect to

the Dynamic Server.


Troubleshooting the sensorThis topic describes common problems that occur with the IBM Informix sensor and presents solutionsfor those problems.

Sensor cannot retrieve server informationProblem

The sensor cannot retrieve information as the Informix Dynamic Server is not started.Solution

Enter the oninit command to start the database server.

Message states that nothing exists to be discoveredProblem

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

SolutionNo active Informix instance is running on the target computer system.

TADDM cannot connect to an Informix databaseProblem

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

SolutionEnsure that the connection from the TADDM server to the Informix port on the database server isopen.

Microsoft SQL Server sensorThe Microsoft SQL Server sensor discovers Microsoft SQL Servers. In TADDM 7.3.0.2, and later, you canuse the sensor in the script-based mode.

Sensor name that is used in the GUI and logsSqlServerSensor


• db.mssql.SqlServer• db.mssql.SqlServerConfig• db.mssql.SqlServerDatabase• db.mssql.SqlServerDataFile• db.mssql.SqlServerModule• db.mssql.SqlServerProcess

PrerequisitesYou must complete the following prerequisite tasks to successfully discover Microsoft SQL Servers.

Note: The following prerequisites are the same for regular and script-based discovery.


Account configurationYou can run the discovery in the Windows or SQL authentication mode.Windows authentication mode

• Create a new login on SQL Server for Windows domain account, which is used for the discoveryof Windows operating system. The discovery is then run in the Windows authentication mode.

• Map the Windows domain account to the login that you created in the previous step.• On the SQL master database, assign the following roles and permissions to the login that you

created for Windows domain account:

– public - open the Login Properties window, go to the User Mapping page, and selectpublic database role.

– db_datareader - open the Login Properties window, go to the User Mapping page, andselect db_datareader database role.

– Connect SQL - open the Login Properties window, go to the Securables page, and grant theConnect SQL permission.

– View any definition - open the Login Properties window, go to the Securables page,and grant the View any definition permission.

These roles and permissions are required to access the following tables:

– sysdatabases– syscurconfigs– sysprocesses– sysobjects– syscolumns

• Open the Login Properties window and go to the Status page. In the setting section, for thePermission to connect to database engine setting, select Grant, and for the Login setting,select Enabled.

• Ensure that the Local Administrators group has SQL access (part of the SQL authorization andconfiguration).

SQL authentication mode

• Create a new login on the SQL Server. Select the SQL Server authentication option. Thediscovery is then run in the SQL authentication mode.

• On the SQL master database, assign the following roles and permissions to the login that youcreated for SQL domain account:

– public - open the Login Properties window, go to the User Mapping page, and selectpublic database role.

– db_datareader - open the Login Properties window, go to the User Mapping page, andselect db_datareader database role.

– Connect SQL - open the Login Properties window, go to the Securables page, and grant theConnect SQL permission.

• Open the Login Properties window and go to the Status page. In the setting section, for thePermission to connect to database engine setting, select Grant, and for the Login setting,select Enabled.

Network requirements

• Depending on the operating system, Level 2 Network Requirements must be met. The application isdiscovered by using an operating system account, therefore TADDM Level 2 discovery of the server,where the application is installed must be successful.

• Microsoft SQL listening ports must be opened on firewalls between TADDM Windows gateways andthe servers, where Microsoft SQL is installed.


Script-based discovery requirementsIn the script-based discovery mode, install either the sqlps Windows PowerShell module, orSqlServerProviderSnapin100 and SqlServerCmdletSnapin100 Windows PowerShell snap-ins.

LimitationsThe transactional dependencies between supported application servers, IBM WebSphere, JBoss, OracleWeblogic, and the SQL Server are only created for the listen port that is stored in the SQL Server'sprimarySap attribute.

If the SQL Server uses general TCP/IP configuration, the ListenAll flag is set to true, then the first staticport is taken as its primarySAP. The rest of the ports are not captured and thus some of the dependenciescannot be created.

If the SQL Server uses specific TCP/IP configuration for each IP interface, the ListenAll flag is set to false,then the first non-loopback, Active, and Enabled IP's first static port is taken as the SQL ServerprimarySAP. The rest of the ports and the ports that are configured for other IP interfaces are notcaptured. Thus some of the dependencies cannot be created.

If the SQL Server uses only dynamic port configuration, the current runtime listen port, which is subject tochange, is not stored in the primarySAP attribute. Instead, a dynamicPortAllocation flag is set to true toindicate it.

The dependencies that are based on the SQL Server instance name, instead of its listening port, arealways created.

The script-based discovery mode of the Microsoft SQL Server sensor relies on the sqlpsmodule, which is available in Microsoft SQL Server 2008, and later. Therefore, if you want to discoverMicrosoft SQL Server 2005, you must have other instances like Microsoft SQL Server 2008, 2008 R2, or2012 installed as well.


Configuring authentication methodsThere are two modes of authentication that TADDM can use to discover an SQL Server.

Windows integrated security authentication.

• Install SSH on the TADDM gateway as required.• For discovery that uses a gateway, enable WMI on all target Windows systems. WMI is enabled by

default.

By default, discovery using a gateway automatically installs the TADDM WMI Provider on all targetWindows systems during the discovery process.

Discovering a SQL Server requires that the Windows Server must be discoverable, but also requires thatadditional access is granted to TADDM.

There are two modes of authentication that TADDM can use to discover an SQL Server:Windows authentication

For Windows authentication, you must meet the following requirements:

• The Windows user used for the discovery of the SQL Server must have the Allow Log onLocally user right on the gateway server.

• The user must have privileges to log on to the SQL Server system. Preferably the user is a domainuser and the server system trusts the domain of the gateway server.

• Add the Windows user and password to the access list for the SQL Server.

SQL Server authenticationFor SQL Server authentication, 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 whichmode the SQL Server is running. Mixed mode supports both types of authentication.

Configuring the access listYou can configure the access list. The TADDM SQL Server access list applies to both Windowsauthentication and SQL authentication mode.

To configure the access list, complete the following procedure:

1. In the Discovery Management Console pane, click Access List.2. Click Add.3. From the Component Type list, select Database.4. From the Vendor list, select Microsoft SQL Server .5. Specify the user name and password.

Note: For SQL authentication mode, enter the SQL Server credentials. For authentication mode, enterthe Windows credentials.

Always provide a separate Windows Computer System access entry for the server to be discoverable.For integrated security, the Windows user ID that is used to access the gateway does not need to bethe same as the one that is used to connect to SQL Server.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Microsoft® SQL Server sensor uses.

Microsoft® SQL Server sensor uses the following sensor settings:

com.collation.discover.agent.SqlServerAgent.UseListeningIpThis value specifies how the display names for SQL Server instance objects are generated.

When the property value is false, the display names for the SQL Server instance objects take thefollowing form: host_fqdn + ":" + sql_server_instance_name

When the property value is true, the display names for the SQL Server instance objects take thefollowing form: sql_server_listening_fqdn + ":" + sql_server_instance_name

The default value is false.

Restriction: You must rediscover the SQL Server to make the changes visible.

com.collation.discover.agent.SqlServerAgent.timeoutThis value specifies the length of time, in milliseconds, that the sensor runs before it times out.

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

com.collation.discover.agent.sqlserver.skipSqlAuthenticationThis value specifies if user wants to skip SQL authentication before Window authentication in SQLServer Sensor or not.

If the property value is false, SQL Server sensor will do SQL authentication before Windowauthentication, else it will skip SQL authentication and try only Windows authentication.

The default value of this property is true. This is because default SQL authentication mode is"Windows".

This property is sensor specific. We can make this setting configurable per machine.

Example com.collation.discover.agent.sqlserver.skipSqlAuthentication.<IP> =true.

Restriction: You must restart and rediscover the SQL Server to make the changes visible.


Troubleshooting the sensorProblems with the sensor might include unsuccessful authorization or discovery, and so on. However, youcan recover from these problems.

The script-based discovery of the Microsoft SQL Server sensor fails

ProblemWhen you run the Microsoft SQL Server sensor in the script-based mode, the discovery fails with thefollowing message:

There was an error while Snapins adding...

SolutionVerify that the sqlps module of Windows PowerShell is installed correctly. The script-baseddiscovery mode of the Microsoft SQL Server sensor relies on this module. However, the module isavailable only in Microsoft SQL Server 2008, and later. Therefore, if you want to discover MicrosoftSQL Server 2005, you must have other instances like Microsoft SQL Server 2008, 2008 R2, or 2012installed as well.

No details available for SQL Server after discoveryProblem

SQL Server is discovered but there are no details provided.Solution

Check that the SQL Server authorization has access to the following tables:

• sysdatabases• sys.master_files• syscurconfigs• sysprocesses

If an SQL Server authorization is not used, check the Windows authorization.

Microsoft SQL discovery without datareader authorityProblem

Is it possible to discover a Microsoft SQL database without having to grant the required db_datareaderrole to the entire database.

SolutionTo discover a Microsoft SQL database, without having to grant authority to the entire database, use thefollowing steps:

• Create a user using the storage procedure from the SQL Server.• Use the sp_addlogin command to create a login that allows users to connect to the SQL Server

using SQL Server authentication.• Use the sp_grantlogin command to allow a Windows user account or group to connect to the

SQL Server using Windows authentication.• After the user is created, grant access to the following tables which are used by SQL server sensor:

sysdatabases, sys.master_files, syscurconfigs, sysprocesses

In the following example the user is taddmusr:

GRANT SELECT on sysdatabases to taddmusr;GRANT SELECT on sys.master_files to taddmusr;GRANT SELECT on syscurconfigs to taddmusr;GRANT SELECT on sysprocesses to taddmusr;


ProductName attribute is not clearProblem

The ProductName attribute does not present enough information about the product.Solution

If you recently migrated from the previous TADDM version, you must rediscover the Microsoft SQLServers. The attribute includes the SQL Server version number, the ServicePack level, and the SQLServer edition.

The ProductName attribute has the following form:

• Microsoft SQL Server 2008 R2 SP1 (Enterprise Edition)

Oracle sensorThe Oracle sensor discovers Oracle Database servers.

Sensor name that is used in the GUI and logsOracleSensor

PrerequisitesThe following requirements must be met:

• Discovery of the computer system must succeed.• Network connectivity between the TADDM server and the Oracle Listener must be functioning.

Security issuesThe Oracle user credentials used to discover an Oracle database from TADDM, must have executeprivileges. To ensure that the correct privileges are granted to the Oracle user, run the followingcommand: 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.

If you are discovering Oracle12c, then there must be privileged common user to discoverOracle12c multitenant architecture. The common user must have sufficient privileges to performoperations in both CDB and PDBs.

To ensure that the correct privileges are granted to the Oracle common user, run the following commandsfrom root container:

1. grant create session to <common_user> container=all;2. grant execute on dbms_system to <common_user> container=all;3. grant SELECT_CATALOG_ROLE to <common_user> container=all;4. grant alter session to <common_user> container=all;5. grant connect, resource to <common_user> container=all;6. alter user <common_user> set container_data=all for v_$pdbs container=current;

To discover Oracle Automatic Storage Management (ASM), the read access must be granted to thefollowing tables and views: dba_clusters, dba_constraints, dba_data_files, dba_db_links,dba_dimensions, dba_indexes, dba_mviews, dba_profiles, dba_role_privs, dba_roles,dba_rollback_segs, dba_segments, dba_sequences, dba_source, dba_synonyms,dba_sys_privs, dba_tab_privs, dba_tables, dba_tablespaces, dba_ts_quotas, dba_users,dba_views, global_name, gv$asm_client, gv$instance, sys.dba_tables, v$asm_diskgroup,v$backup, v$bgprocess, v$controlfile, v$database, v$datafile, v$log, v$logfile, v$parameter, v$pgastat, v$process, v$session, v$sga, v$sys_optimizer_env, and v$version.


If you are discovering Oracle18c or Oracle 19c, then there must be privileged common user todiscover the multitenant architecture. The common user must have sufficient privileges to performoperations in both CDB and PDBs.

Oracle RAC discoveryOracle RAC Discovery.

For RAC discovery:

Note:

1. Ensure that discovery user MUST have proper Oracle authorization to run the RAC commands:crs_stat -v, or crsctl status resource -v in case of later oracle releases, andsrvctl.

2. For Oracle 11.2g onwards, at least one SCAN listener shall be present.

RAC discovery informationThis topic describes RAC discovery.

In case of Oracle 11.2g and later versions

GenericServer Sensor MAY launch multiple Oracle sensor in case of RAC setup, based on matchingtemplate.

As there can be more than 1 Oracle listener present and listening on multiple RAC IPs (e.g. VIP, SCANIP) on a given RAC node, hence in this case, these Oracle Sensors will discover the same data, thusresulting in duplicates.

In Oracle RAC environment, TADDM discovers only those nodes that have SCAN IP configured. Forother nodes and instances, TADDM discovers limited information.

To avoid redundant or duplicate Oracle Instances discovery, Oracle sensor will only complete thediscovery using first SCAN IP of given RAC node. The Oracle process must be listening on this IP fordiscovery to continue.

All other Oracle sensors having different RAC IPs (e.g. VIP, non-first SCAN IPs) will not continue andstop with a Warning messages like CTJTD1048W and CTJTD1049W.

Prior to Oracle RAC 11.2g

There is no such dependency related to SCAN IP.

Configuring the collation.properties file entriesThis topic lists additional collation.properties file entries that the sensor uses to discover Oracle RAC.

com.collation.oracle.sensor.sudo.srvctl.<context-IP>=false

This property is used to configure srvctl command to run as sudo.

Set this property to 'true', if the discovery user does not have authorization to run the srvctlcommand.

Here, <context-IP> is the IP of the target being discovered, as provided in the Discovery Scope.

If <context-IP> is not specified, this will apply globally.

Default value is false.

com.collation.oracle.sensor.sudo.crsstat.<context-IP>=false

This property is used to configure crsstat command to run as sudo. Set this property to 'true' if thediscovery user does not have authorization to run the crsstat command.

Here, <context-IP> is the IP of the target being discovered, as provided in the Discovery Scope.

If <context-IP> is not specified, this will apply globally.


Default value is false.

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

Oracle sensor now also supports asynchronous or script-based discovery on windows platform.

For specific versions, see Sensors and supported target systems in the TADDM Wiki.


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


For script-based discovery, the owner of the Oracle_home directory must be defined in the access list asthe Oracle user credential. The script sensor specifically locates this user to run the Oracle databasequeries. If this user is not defined in the access list, the sensor returns the error "CTJTP1186E The entriesin the access list are not applicable".

Note: The operating system user which starts the sensor by using the computer system credentials musthave the read access to the /etc/oratab or /var/opt/oracle/oratab files to become the owner ofthe Oracle_home directory.

Complete the following steps:

1. Select Database as the component type.2. Select Oracle as the vendor.3. Specify the following required information:

• The operating system user name for the Oracle user• The operating system password for the Oracle user

LimitationsSome function that is provided by the Oracle sensor during a non-script-based discovery is not supportedin an asynchronous or script-based discovery.

The following functions are not supported:

• Application descriptor discovery• Oracle RAC discovery• Oracle ASM discovery• Raw schema discovery (the list of tables in the database is limited)• OracleDBLink model object discovery• OracleListener model object discovery

Detailed information (like Tablespace, Schema and History) for Pluggable Database won’t bediscovered in case the given PDB is in “MOUNTED” state, in case of Multi-tenant Oracle database.

TADDM supports discovery of upto 252 Pluggable Databases in a given container database.



Model objects with associated attributesThe Oracle sensor creates model objects with associated attributes. The attributes indicate the type ofinformation that the sensor collects about configuration items in the Oracle environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.OracleASM

AsmInstancesDiskGroupsNameNodeRac

OracleASMDiskAsmDiskGroupStateName

OracleASMDiskGroupAsmAsmDisksNameState

OracleASMInstanceBackgroundProcessesDatabaseHostHostnameOracleInstanceStatusParametersParentPortRacDatabaseSGAValuesSIDServerProcesses

OracleBackgroundProcessDescriptionNamePid

OracleControlFileName

OracleDBLinkIpAddressPortServiceName

OracleDataFileName


SizeTableSpace

OracleDatabaseControlFilesDBNameDBVersionDataFilesInitValuesNameRedoLogFilesSchemaRawDataSchemasTableSpaces

OraclePluggableDatabase

OraclePDBHistoryOracleInitValue

DescriptionNameValue

OracleInstanceBackgroundProcessesConfigContentsDatabaseHostKeyNameModulesNamePortPrimarySAPProcessPoolsProductNameProductVersionSGAValuesSIDServerProcessesStatus

OracleListenerBindAddressesName

OracleModuleFileNameNameSchema


OracleRACAsmHomePathNameOCRLocationPrimaryNodeRacDatabasesVoteDiskPath

OracleRedoLogFileNameSize

OracleSGAValueNameValue

OracleSchemaNameOwner

OracleServerConfigFileListeners

OracleServerProcessConnectionsNamePIDPorts

OracleTableSpaceNameSize

ProcessPoolNameRuntimeProcesses


Copying the JDBC driverThis topic describes how to copy a JDBC driver for the Oracle sensor.

Important: If you use TADDM 7.3.0, or 7.3.0.1, the Oracle sensor requires the classes12.jar file to becopied. Optionally, in addition to this file, you can also copy later versions of the driver, for exampleojdbc7.jar, as described in the following procedure.

If you use TADDM 7.3.0.2, or later, only one file is required. Copy the driver that is compatiblewith the latest version of the Oracle that you discover, for example ojdbc7.jar. Optionally, you can copymore versions of the driver.

To copy the JDBC driver, complete the following steps:

1. Get the JDBC driver file, for example classes12.jar, or ojdbc7.jar file from the Oracle website orfrom the Oracle installation media.

2. Copy the file to the following location:


$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.db.oracle.oraclecommon_1.0.1/lib/oracle

3. Add the name of the JDBC driver file to the Bundle-ClassPath entry in the MANIFEST.MF file of theOracleCommon sensor.

a. Go to the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.db.oracle.oraclecommon_1.0.1/META-INFdirectory and open the MANIFEST.MF file in a text editor.

b. Check whether the Bundle-ClassPath entry contains the name of the JDBC driver that you wantto copy. The following example shows the correct entry for the ojdbc8.jar file:

Bundle-ClassPath: lib/oracle/ojdbc8.jar, lib/oracle/ojdbc7.jar, lib/oracle/ojdbc6.jar, lib/oracle/ojdbc5.jar, lib/oracle/classes12.jar

c. If the entry does not contain the name of the driver that you want to copy, add the name manuallyas the first entry.




1. Select Database as the Component Type.2. Select Oracle as the Vendor.3. Specify the following required information:


To discover Oracle Automatic Storage Management (ASM) file systems, type the user name sys andpassword.


com.collation.discovery.oracle.extendedThis property specifies whether additional configuration values about Oracle database links arestored.

The default value is N (No).

If you set the property to Y (Yes), the sensor stores additional configuration values about Oracledatabase links.






com.collation.discovery.oracle.tablelimitThis property controls the quantity of tables that are discovered by Oracle sensor.

The default value is 1000. The property supports only positive values.

com.collation.oracle.sensor.ignoreNonRegisteredSidOfListener=trueThe default value of this property is false.If this property is set to true, the Oracle Sensor will ignore those SIDs which are found to be notregistered on Oracle listener.

Oracle Sensor first tries to establish a jdbc connection with the listener for a SID. If it gets an error"ORA-12505, TNS: listener does not currently know of SID given in connectdescriptor", the SID is ignored. If the connection is unsuccessful with any other error, a shallowOracle Instance Model Object is created with this listener's IP and Port details.

Another impact to this property is that, it will not create those Oracle instances which have notregistered with any listener.

Note: In Fix Pack 6, this property is replaced bycom.collation.oracle.sensor.CreateOnlyConfirmedRegisteredSid=true

com.collation.oracle.sensor.CreateOnlyConfirmedRegisteredSid=trueThe default value of this property is true. For true value:

• Oracle Sensor will only create Oracle Instances for SIDs for which Jdbc connection is success on thelistener. Success of jdbc connection act as a confirmation that the SID is registered on the currentlistener for which the sensor is invoked. The model object will be created with this listener’s IP orPort details

• It will also create shallow Oracle Instance for SIDs where we get this error "ORA-01017: invalidusername/password; logon denied". This is because jdbc driver throws this error after it hadchecked that SID is registered with listener

If the value set to false:

• Sensor will create shallow Oracle Instance for SID even if sensor is not able to establish Jdbcconnection to the SID on this listener for which sensor has invoked. This means that if the targetsystem has only single listener and all SID are registered on it, but jdbc connection is failed becauseof any reason, then shallow Oracle Instances will get created with the listener’s IP or Port details.But if the target has multiple Listeners and each listener is listening on different virtual IP or Port,then Oracle Instances may get created with any random Port even if its listener is not listening onthat port or Virtual IP

Note: This property setting will be ignored in case “Light level Oracle discovery” is enabled. Thisproperty can be scoped to level of a particular IP address eg,com.collation.oracle.sensor.CreateOnlyConfirmedRegisteredSid.1.2.3.4=false.

The above configuration will be applicable to only selective IP ,e.g. 1.2.3.4

com.collation.oracle.sensor.cmd.prefixThis is an optional property and is used to specify a text that will be prefixed with the Oraclecommands executed by this sensor.Some of the Oracle commands executed by this sensor are: srvctl config scan, crs_stat -v etcThis property can also be specified as per OS and targets.In the following example, before actual execution of the command, specified Oracle user profile willbe sourced to set up the requisite environment variables.com.collation.oracle.sensor.cmd.prefix.linux.<context_ip> =. /app/grid/home/.profilecom.collation.oracle.sensor.cmd.prefix.linux=. /app/grid/home/.profile


com.collation.oracle.sensor.cmd.prefix=. /app/grid/home/.profilecom.collation.discover.agent.OracleAgent.pdb.seed=true

The default value of this property is true. If this property is set to true, the Oracle Sensor will discoverdetails of the PDB seeds. If the value is set to false, then for performance optimization, Oracle Sensorwill discover seed PDBs but will skip its details like DBVersion, TableSpaces, Schemas, PDBHistoryand DBLinks.

com.collation.discover.agent.OracleAgent.pdb.maxPoolSize=10The default value of this property is 10. This is an optional property and set the maximum size ofthread pool for parallel processing of PDB's in multiple threads.

Configuring deepDiscoveryLevel=trueThis configuration option is visible in Oracle Sensor’s configuration view under Discovery Console and isused to specify whether OracleSensor shall perform light level discovery or deep level discovery.

Deep level Oracle discoveryIn this mode, oracle sensor will create the JDBC connection with Oracle DB and discover all the modelobjects supported by Oracle sensor. Hence, a valid and privileged Oracle database user must bepresent in the TADDM access list.

Light level Oracle discoveryIn this mode, oracle sensor will not create any JDBC connection with the Oracle database. Therefore,it is optional to add database type credentials in TADDM access list. Since no JDBC connection iscreated sensor shall only be able to discover basic details about the Oracle sensor using the Oracleconfiguration files.

Below information can be discovered in light level discovery:

1. Oracle Home2. SID3. Config Files4. RAC (Partial)

Default value for this option is true, thus enabling deep level discovery of oracle databases by default.

Note: There is a limitation in case of Light level Oracle Discovery as follows: when the target hasmultiple listeners and each listener is listening on different virtual IP or Port, then Oracle Instancesmay get created with any random Port or virtual IP’s FQDN, even if its listener is not listening on thatport or Virtual IP.

Troubleshooting the sensorThis topic describes common problems that occur with the Oracle sensor and presents solutions for thoseproblems.

Oracle sensor does not startProblem

The Oracle signature is not matching because either you have renamed the Oracle binaries or you arerunning a version of the Oracle server that TADDM does not support (Express Edition, for instance).

SolutionDo not change the names of the binaries and ensure you are using a supported version of Oracle. Alsomake sure that the TNSListener service is started for the Oracle database.

Sensor fails with "Unable to find the servers" errorProblem

The Oracle database account is not functioning because of one of the following reasons:

• The password is not correct.


• The account is locked.• The account does not have connect privileges.

SolutionUpdate the access list, unlock the account, or add the connect privilege.From the command prompt, test the account by running the sqlplus command, as shown in thefollowing example:

bash-2.05b$ sqlplus

SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jun 12 08:15:23 2007Copyright (c) 1982, 2005, Oracle. All rights reserved.Enter user-name: systemEnter password:ERROR:ORA-28000: the account is locked

Important: Below points captures the solutions to the common problems that occur in case of OracleRAC discovery:

Oracle RAC is not discovered

ProblemOracle RAC is not discovered.

SolutionVerify that the discovery user has sufficient privileges to execute RAC commands.

Oracle Sensor executes commands like “srvctl”, “crs_stat”, “cemutlo” and in case any of thesecommand fails, then it may lead to failure in discovery of RAC or Database Instances. This may alsoresult in duplicate Oracle instances.

Oracle Sensor finished with a warning message CTJTD1048WProblem

Oracle sensor finished with a warning message as shown below:

"CTJTD1048W Oracle RAC environment has been detected. The current Oracle SID IP does notrepresent the SCAN IP. The discovery will be completed using a sensor through one of SCAN IPs".

SolutionFor Oracle 11.2g onwards, sensor will continue the discovery only in case of SCAN IP. For all other IPs,Oracle sensor will complete with a warning message: CTJTD1048W. This is expected behaviour andcan be ignored in case of RAC setup.

Oracle Sensor finished with a warning message CTJTD1049WProblem

Oracle sensor finished with below warning message as shown below:

"CTJTD1049W Oracle RAC environment has been detected. The current Oracle SID IP does notrepresent the first SCAN IP. The discovery will be completed using a sensor through this SCAN IPs".

SolutionFor Oracle 11.2g onwards, when a RAC node has more than one SCAN IP configured on it, then thediscovery will always be completed using the first SCAN IP (for this node), as determined from the“srvctl config scan” output. For all other SCAN IP, sensor will complete with warning message:CTJTD1049W.This is expected behavior and can be ignored in case of RAC setup.


Oracle duplicates occur when instances are discovered by both Veritas clustersensor and Oracle sensorProblem

When you use both Veritas cluster sensor and Oracle sensor to discover an Oracle instance, duplicatesmight occur. This happens because Veritas cluster sensor uses the upper case for the instance SIDand Oracle sensor uses the lower case for the same SID.

SolutionTo avoid this problem, modify the dist/etc/discover-sensors/VeritasClusterSensor.xmlfile by changing the following line:

<source>Sid</source>

into the following line:

<source>%{Sid}</source>

After the change, Veritas cluster sensor creates Oracle instances with the lower case SID.

Note: If you change the line after running discoveries where no duplicates occurred, new duplicatesmight occur.

During Oracle RAC Discovery, all OracleInstance objects are not linked to theOracleRAC object

ProblemDuring Oracle RAC Discovery, Oracle instances are discovered but all OracleInstances objects are notlinked to the OracleRAC object or linked OracleInstance objects gets deleted after an agentOracleDependencyAgent runs.

SolutionTo avoid this problem, set the following two property to ‘true’ in collation.properties file onthe discovery server. By default, it is 'false'. For more details, refer https://www.ibm.com/support/pages/apar/IJ26967

1. com.collation.oracle.sensor.rac.UseHostnameOfCrsStatForMerge=true

2. com.collation.oracle.sensor.rac.AccessOtherScanNodes=true

Setting the above properties will result in improved linking between OracleRAC object andOracleInstance objects.

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

To discover the Sybase database, the sensor uses JDBC protocol with the ENCRYPT_PASSWORDand RETRY_WITH_NO_ENCRYPTION flags set to true by default. It means that the password is encryptedand that if you fail to authenticate in your first attempt, the passwords provided during next attempts arenot encrypted. The connection is secure if the access list entry contains a trust store file.

Sensor name that is used in the GUI and logsSybaseSensor


https://www.ibm.com/support/pages/apar/IJ26967

https://www.ibm.com/support/pages/apar/IJ26967

Security issuesTo assign the minimum privileges to the Sybase discovery user, run the following command:

grant select on sysengines from public

The following tables are queried:

• 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

The previous query discovers only the information for the master database. If you want to discoverinformation about users and tables from other databases, create a user id on these databases. During thediscovery, TADDM runs the following query:

select t.segment, u.name from database_name..systhresholds t,database_name..sysusers u where t.suid=u.suid

Examples:

• The following query is run for the tempdb database:

select t.segment, u.name from tempdb..systhresholds t,tempdb..sysusers u where t.suid=u.suid

• The following query is run for the sybsystemprocs database:

select t.segment, u.name from sybsystemprocs..systhresholds t,sybsystemprocs..sysusers u where t.suid=u.suid

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

• The limitation in SAP Sybase ASE software identified by CR# 751110 affects TADDM.Database connection configured to use secure socket layer (SSL) hangs while connecting to servers thathave SSL mode disabled. The avoid such problem in TADDM, set a value of the following scopedproperty:

com.collation.sybasesensor.jdbclogin.timeout


The default value is 15000 ms (15 seconds). After that time, attempts to log in fail and sensor tries toestablish a plain unsecured connection.

• In TADDM 7.3.0.3, and later, the following configuration elements are not discovered bydefault:

– logins– roles– rawSchema– tables– thresholds

If you want these elements to be discovered, create a sensor configuration in Discovery ManagementConsole, and set the following properties to true:

– discoverLogins– discoverRoles– discoverRawSchema– discoverTables– discoverThresholds

Model objects with associated attributesThe Sybase sensor creates model objects with associated attributes. The attributes indicate the type ofinformation that the sensor collects about storage resources in your IT environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.AppConfig

• Content• Parent

ConfigFile

• FixedPath• RealFile• URI

LogicalContentFixedPath

ProcessPool

• CmdLine• Env• Name• Parent• RuntimeProcesses

SybaseConfigValue

• ConfigUnit• Name• Parent• RunValue• Type


• Value

SybaseDatabase

• Name• Options• Owner• Parent (SybaseServer)• SchemasRawData• Segments• Tables• Thresholds• Users

SybaseDevice

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

SybaseEngineProcess

• CmdLine• Name• PID• Parent• Ports

SybaseLogin

• AccumulatedDate• FailedLoginCount• FullName• IsAccountLocked


• IsPasswordExpired• Language• Name• Parent(SybaseServer)• PasswordDate• SybaseRoles• TotalCPUUsed• TotalIOUsed

SybaseModule

• Database• FileName• Name• Parent

SybaseRemoteServer

• IsMessageConfidential• IsMessageIntegrity• IsMutualAuthentication• IsNetworkPasswordEncrypted• IsReadOnly• IsRPCSecurityModelB• IsTimeoutEnabled• Name• NetworkName• RemoteNetworkCost• RemoteServerClass• SybaseServer

SybaseResourceLimitation

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

SybaseRole

• FailedLoginCount• Name• Parent


• PasswordDate• Status

SybaseSegment

• Name• Parent• Size

SybaseServer

• BindAddresses• ConfigContents• ConfigFile• ConfigValues• Databases• Devices• EngineProcesses• FullVersion• Home• Host• KeyName• Logins• Modules• Name• PrimarySAP• ProcessPools• ProductName• ProductVersion• RemoteServers• ResourceLimitations• ServerProcesses• Status• SybaseRoles• TimeRanges

SybaseServerProcess

• Name• PID• Parent

SybaseTable

• CreationDate• Name• Parent(SybaseDatabase)• Partitions

SybaseTablePartition

• FirstPage


• NumPages• Parent (SybaseTable)• PartitionID

SybaseThreshold

• IsLastChance• Name• Parent (SybaseDatabase)• Segment• ThresholdExeededProcedure• ThresholdSize• User

SybaseTimeRange

• EndDay• EndTime• Name• Parent (SybaseServer)• StartDay• StartTime

SybaseUser

• Login• Name• Parent (SybaseDatabase)



1. Select Database as the Component Type.2. Select Sybase as the Vendor.3. Specify the access information (user name and password) that TADDM should use to establish a JDBC

connect to the Sybase server.

4. Depending on your server configuration, specify the SSL truststore file with the pass phrasein the SSL Settings. This applies only to the discovery that uses the SSL connection.

Note: Due to a Sybase JDBC driver and JVM limitation, only one truststore file can be used during adiscovery. Therefore, if you want to discover many Sybase targets over the SSL protocol, you must addonly one truststore file that contains all required certificates. This file must be added to the first accesslist entry of the Sybase sensor in TADDM. Other entries cannot contain any SSL Settings. You can usethe keytool and ikeyman tools to create the truststore file. Both tools are in the$COLLATION_HOME/external/jdk-os-platform/jre/bin directory.

Configuring the discovery profileYou can customize the settings of the Sybase sensor, if the default ones do not meet your requirements.

To customize Sybase sensor settings, you must create a sensor configuration. Complete the followingsteps:

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


2. In the Discovery Profiles window, click New.3. In the Create New Profile window, type the profile name and description. From the Clone existing

profile list, select Level 3 Discovery and click OK.4. On the Sensor Configuration tab, select the SybaseSensor sensor and click New.5. In the Create Configuration window, type the name and description for your configuration, and select

the Enable this configuration and disable selected configuration check box.6. In the Configuration section of the Create Configuration window, modify any or all of the properties.7. Click OK to return to the Discovery Profiles window.8. In the Discovery Profiles window, click Save.

PropertiesYou can modify the following properties:

discoverLoginsSpecifies whether the logins data is discovered during a Sybase database discovery.The default value is false, which means that the data is not discovered. To discover logins, set thisproperty to true.

discoverRolesSpecifies whether the roles data is discovered during a Sybase database discovery.The default value is false, which means that the data is not discovered. To discover roles, set thisproperty to true.

discoverRawSchemaSpecifies whether the rawSchema data is discovered during a Sybase database discovery.The default value is false, which means that the data is not discovered. To discover rawSchema, setthis property to true.

discoverTablesSpecifies whether the tables data is discovered during a Sybase database discovery.The default value is false, which means that the data is not discovered. To discover tables, set thisproperty to true.

discoverThresholdsSpecifies whether the thresholds data is discovered during a Sybase database discovery.The default value is false, which means that the data is not discovered. To discover thresholds,set this property to true.

Sybase IQ sensorThe Sybase IQ sensor discovers Sybase IQ database servers.

Sensor name that is used in the GUI and logsSybaseIQSensor

Security issuesTo assign the minimum privileges to the Sybase discovery user, run the following command:

grant execute on sp_iqdbsize



• app.AppConfig• app.ConfigFile• app.db.sybase.SybaseConfigValue• app.db.sybase.SybaseDatabase• app.db.sybase.SybaseDevice• app.db.sybase.SybaseEngineProcess• app.db.sybase.SybaseModule• app.db.sybase.SybaseServer• app.ProcessPool• core.LogicalContent



1. Select Database as the Component Type.2. Select Sybase as the Vendor.3. Specify the access information (user name and password) that TADDM should use to establish a JDBC

connect to the Sybase server.

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

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

Sensor name that is used in the GUI and logsAnchorSensor

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

If anchor is deployed on 64-bit Linux systems, JBossSensor and StackScanSensor require also 32-bitversion of the libgcc and glibc libraries.



The TADDM server uses SSH to communicate with the remote anchor server. To configure the access list,complete the following steps:

1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM must use for either SSH key-

based authentication or SSH login-based authentication to the remote anchor server.


Typically, an account with non-root privilege can be used. However, some commands that TADDM usesduring the discovery process can require privilege escalation (typically done using the sudo command).

For more information, see the Commands that might require elevated privilege topic in the TADDMAdministrator's Guide.

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


com.collation.discover.anchor.zone.fromContextIPSpecifies whether the anchor zones can be set from the context IP, which is the IP that is used for thediscovery. Valid values are true and false. The default is false.When an IP address is not included in the anchor scope, the anchor zone is not set. As a result, theaddress space is not set for a particular IP address or IP network. If you set this property to true, theanchor zones are set from the context IP.

com.collation.discover.agent.AnchorSensor.timeout=3600000Specifies the time allowed to start a new anchor server.

com.collation.discover.anchor.forceDeployment=trueThe default value is true.

This property specifies whether the anchors for the discovered scope are to be deployed duringdiscovery startup.

If you set the value to false, the anchors are deployed only if either of the following conditions aremet:

• If any IP address from the scope cannot be pinged• If port 22 cannot be reached on any of the discovered IP addresses

If chained anchors exist, this condition applies to all anchors in the chain. If an anchor in the chain isrestricted with a condition, the prior anchors must meet the condition before all the anchors can bedeployed.

com.collation.discover.anchor.lazyDeployment=falseSpecifies if files must be copied during anchor deployment, or when the sensor requiring the files isgoing 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 directorywhich are 130 MB in size. If the flag is set to false, this data is copied to the target host when theanchor is deployed. If the flag is set to true, the data is copied when the WebSphere ApplicationServer sensor is about to be run on the anchor. If no WebSphere Application Server sensor is runthrough the anchor, 130 MB is not sent to the remote host.

com.collation.discover.anchor.connectType=sshSpecifies whether to connect to the anchor using an ssh tunnel or a direct socket. Valid values are sshand direct. The default is ssh. To specify the connection type for a particular address, usecom.collation.discover.anchor.connectType.1.2.3.4=ssh, where 1.2.3.4 is the addressfor which you want to specify the connection type.

com.collation.platform.session.GatewayForceSshSpecifies whether to force the gateway to act independently of the anchor. Valid values are true andfalse. Set the value to true to resolve Cygwin issues when both the gateway and anchor are on thesame system. When the value is set to true, an SSH session is used to transfer traffic between thegateway and anchor rather than a local session.


Asynchronous discovery sensorThe asynchronous discovery sensor is required for asynchronous discovery. IP addresses that areunreachable (cannot be pinged) are candidates for asynchronous discovery. The asynchronous discoverysensor attempts to determine which of the unreachable IP addresses are valid.

For information about asynchronous discovery, see the Asynchronous discovery topic in the TADDMAdministrator's Guide.

In asynchronous discovery, the output of the discovery script is an archive file that contains the discoveryresults and is stored in a directory on the TADDM server. An unreachable IP address is considered valid ifan archive file exists on the TADDM server for that IP address. Based on the content of the archive file, theappropriate sensors are scheduled to process their discovery script output. Sensors then performdiscovery by parsing the script output instead of directly accessing the target system, as is done in anonscript-based discovery.

Sensor name that is used in the GUI and logsASDSensor

Configuring the sensorThe asynchronous discovery sensor does not use the access list.

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

• com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory• com.ibm.cdb.discover.asd.ProcessUnreachableIPs• com.ibm.cdb.tarpath

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

The sensor does not discover any objects and fails with error CTJTD3078EProblem

The ASDSensor finishes with no objects discovered and the following error is issued:

CTJTD3075E Unable to execute command: tar -xf <asdfile> command exit code: 1.In addition in the logs following erorr appears:tar: can't create ././@LongLink: Permission denied

SolutionYour tar program must support long file paths. GNU Tar 1.13 is not supported because it mighttruncate long file names.

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

Sensor name that is used in the GUI and logsASDPingSensor


PrerequisitesIn a discovery profile, if you are using the asynchronous discovery ping sensor, you must disable the pingsensor because you cannot enable both of these sensors in a discovery profile.

Custom application server sensorThe custom application server sensor creates a custom application server that is based on template andruntime process information that is discovered by the generic server sensor. The sensor also collectsconfiguration files or application descriptors if these are specified in the template and performs extensionprocessing to collect additional information.

Sensor name that is used in the GUI and logsCustomAppServerSensor

PrerequisitesTo discover configuration files, the sensor requires that the cksum program and associated libraries areinstalled on the target operating system.


• The sensor cannot be run in script-based discovery.• The same limitations as for the “Generic server sensor” on page 212 apply.

Model objects createdThe following model objects are used to create generic AppServers:

• app.AppServer• app.db.DatabaseServer• app.j2ee.J2EESever• app.web.WebServer

The following model objects are used to extend TADDM application sensors:

• 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• app.veritas.cluster.VCSCluster• app.web.apache.ApacheServer• app.web.iis.IIsWebServer• app.web.iplanet.IPlanetServer


Custom MIB2 computer system sensorThe custom MIB2 computer system sensor creates a custom computer system that is based on templateinformation.

This template information is matched for one or more of the following items:

• system OID (SNMPv2-MIB::sysObjectID - .1.3.6.1.2.1.1.2)• system Description (SNMPv2-MIB::sysDescr - .1.3.6.1.2.1.1.1) discovered by the SNMP MIB2 sensor

The custom MIB2 computer system sensor performs extension processing to collect additionalinformation.

Sensor name that is used in the GUI and logsCustomMib2ComputerSystemSensor

LimitationsSee the limitations for the SNMP MIB2 sensor.


• sys.ComputerSystem hierarchy

Custom template sensorThe custom template sensor can be used with custom scripts to analyze and enhance the information thatis collected by other sensors. For example, if additional data or information is required, of aModel Object, than discovered by an existing TADDM sensor, then a custom template sensor can be usedto fetch the extra data and set it against the discovered model object. The existing model object,discovered by an existing TADDM sensor, is given as an input to the custom template sensor which canenrich it further. Through the custom template sensor, the user can execute additional commands on thetarget and save the result in appropriate attributes of the existing discovered result object. Users can alsodefine extended attributes on the model object type and then use custom template sensor to set theextended data in the input object. User can also use the result of another sensor and analyze or constructany different model objects.

Sensor name that is used in the GUI and logsCustomTemplateSensor

LimitationsThe sensor cannot be run in script-based discovery.

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

The custom template sensor is not enabled by default. To enable the sensor, you must create a discoveryprofile and then enable the sensor in the new profile. You must also enable in this profile any additionalsensors that you want to analyze the results from.

You must create a template for the custom template sensor. This template consists of the following files:template.xml

This file contains the configuration data. In this file, you specify the TADDM result class object that youwant to analyze.


matcher-script.pyThis script extracts the specified model objects that are then processed by the sensor-script.pyfile.

sensor-script.pyThis script can modify objects, create model objects, and store model objects.

You must place these files in the $COLLATION_HOME/etc/templates/cts/template_name directory.The name of the directory template_name must match exactly the name as specified in thetemplate.xml file.

To run the discovery, read access rights to the templates directory and its associated files are required.

The scripts are Jython scripts. See the SDK Developer’s Guide for information about the custom serverextensions API. General script-related information in this guide can be applied to the custom templatesensor scripts. Detailed information about code related to initializing the environment, importing TADDMsensor tools, and logging errors can be used when defining the sensor scripts. All script files must beplaced in the $COLLATION_HOME/etc/templates/cts/template_name directory.

Template.xml

The template.xml file has the following structure:

<CTSTemplate> <name>template_name</name> <result-class>com.ibm.cdb.discover.app.db.db2.result.Db2Result</result-class> <plugin-id>com.ibm.cdb.discover.sensor.app.db.db2.db2_7.6.0</plugin-id> <engine-id>com.ibm.cdb.core.jython253_2.5.3</engine-id> <matcher-script>matcher.py</matcher-script> <sensor-script>sensor.py</sensor-script></CTSTemplate>

In the above example, the template specifies that the Custom Template Sensor needs to runafter the sensor defined in the plugin-id tag (DB2 in this case) has generated the result to be analyzed.

Important: You must arrange the elements of the template.xml file exactly like in the precedingexample. Otherwise, errors are generated.

nameThe template name. For example, if the template name is example_template, then you must have thedirectory structure: $COLLATION_HOME/etc/templates/cts/example_template.

result-classThe fully qualified name of the TADDM result class that you want to analyze.

plugin-idThis plugin-id specifies the ID of the plug-in that provides the results. This ID is required for pluggablesensors only.

engine-idThis engine-id specifies the IP of the plug-in that provides the Jython engine to be used, for examplecom.ibm.cdb.core.jython253_2.5.3. If not specified, the default engine is used.

matcher-scriptThe name of the Jython script (.py extension) that lists all of the objects that meet the criteria definedin the script.

sensor-scriptThe name of the Jython script that processes the list of objects generated from the result-matcherscript. Depending on the object returned the script modifies the objects or creates new objects. Theseobjects can then be stored.

Matcher script

This script is run when the result object of the class specified in the template is discovered. The followinginformation is provided to the script from the sensorhelper code:


• The ResultMap is a map of the model objects, their arrays, or collections. These objects are the sharedproperties of the result object that are matched by the template. The map is indexed by property name.

• The ReturnList contains a list of elements that require further processing. Each element is associatedwith the name that is displayed as the sensor starts for that element.

When the result matcher script completes successfully, this information is used to seed the customtemplate sensor.

This script example shows the steps that extract objects from the discovery results of the generic serversensor.

# Initialising the environmentimport sysimport java

from java.lang import Systemcoll_home = System.getProperty("com.collation.home")

System.setProperty("jython.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib")System.setProperty("python.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib")

jython_home = System.getProperty("jython.home")sys.path.append(jython_home + "/Lib")sys.path.append(coll_home + "/lib/sensor-tools")sys.prefix = jython_home + "/Lib"

import traceback

# Importing sensorhelperimport sensorhelper

# Initialising script input(resultMap,returnList,log) = sensorhelper.init(targets)log.debug("CTS result matcher script running")

try: # get runtime processes list from the result runtimeProcesses = resultMap['runtimeProcesses'] # get first of the processes rtp = runtimeProcesses[0][0] # add it to the list of elements that need further processing returnList.add("dummyName",rtp) except: log.error("Error occurred")

You can use an XPath query when using the JXPath library to determine which of the objects are returned.The findElementsForXPath function can be used to query and return a collection of objects resultingfrom the query. The following example finds and prints an IP address using the findElementsForXPathfunction. See the SDK Developer’s Guide for information about this utility function.

result = IpListResult();ip1 = IpAddressImpl();ip1.setStringNotation("9.0.0.1");ip2 = IpAddressImpl();ip2.setStringNotation("9.0.0.2");result.list.add(ip2)result.list.add(ip1)

elements = sensorhelper.findElementsForXPath(result,"/list[stringNotation='9.0.0.2']")for e in elements: print e

Sensor script

This script starts separately for each of the extracted objects returned from the result-matcher script.Depending on the objects returned, the script modifies, creates, and populates the model objects. These


objects can then be stored. The following information is provided to the script from the sensorhelpercode:

• The CTSSeed object that contains the ResultMap and the name value pair returned by the resultmatcher script.

• The CTSResult object is a custom template result object that is populated by the sensor script with themodel objects that can be stored.

This script example shows the steps that populate and store model objects.

import sysimport java

from java.lang import Systemcoll_home = System.getProperty("com.collation.home")

System.setProperty("jython.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib/jython-2.1")System.setProperty("python.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib/jython-2.1")

jython_home = System.getProperty("jython.home")sys.path.append(jython_home + "/Lib")sys.path.append(coll_home + "/lib/sensor-tools")sys.prefix = jython_home + "/Lib"

import tracebackimport sensorhelper

(ctsResult,ctsSeed,log) = sensorhelper.init(targets)

log.debug("CTS Sensor script running")# get value passed by result matcherruntime_process = ctsSeed.getSeedInitiator().getValue()# get name passed by result matchername = ctsSeed.getSeedInitiator().getKey()templateName = ctsSeed.getTemplate().getName();log.debug("CTS Sensor script running for template " +templateName + “/” + name)# process runtime process with user defined functionresult = processRuntimeProcess(runtime_process) # return resulting model objectctsResult.addExtendedResult(result)

Besides the above example, a more common scenario is to fetch data by running commandsdirectly on the target using methods sensorhelper.executeCommand orsensorhelper.executeCommandWithTimeout and then store the output result in the extendedattribute of the model object.

The following code snippet added in the matcher and sensor-script for instance obtains the version for aJboss product.

# Matcher script snippet:# add all results of resultMap (not filtering) to returnListreturnList.add(sensorName,resultMap) # Sensor script snippet:# get the appServer model object from value passed by result matcherinitValue = ctsSeed.getSeedInitiator().getValue()server = initValue.get('appServer')if str(server) == 'None': server = initValue.get('domain')os = sensorhelper.getNewOsHandle(server.getContextIp())# execute command on jboss target (os) and fetch versionversionResult = sensorhelper.executeCommandWithTimeout("cat /opt/Jboss/EAP-7.1.0/version.txt | sed '/^$/d'", 100000, os)# set extended attribute ProductVersion’ in appServer or domain model objectsensorhelper.setExtendedAttributes(server, {'ProductVersion': versionResult})ctsResult.addExtendedResult(server)

In the above example, before running the CTS sensor, an extended attribute named'ProductVersion’ must be defined for the appropriate model object type on the TADDM Data ManagementPortal (DMP). For more details, refer to the 'Creating extended attributes in Domain Management Portal'topic in the SDK Developer's Guide.


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

The custom template sensor does not start or failsProblem

There are a number of potential situations that can prevent the sensor from starting or cause it to fail.Solution

Verify that the following conditions exist:

• The custom template sensor is enabled in the discovery profile.• The custom template sensor template and scripts are located in the correct directory.• The name of the directory that stores the template matches the name that is specified in thetemplate.xml file.

• The format of the template.xml file is valid.• The result-class that is specified in the template.xml file exists and, if required, the plugin-id isspecified.

• The scripts (matcher-script.py and sensor-script.py) are in the correct directory and aredefined correctly in the template.xml file.

• The scripts contain no syntax errors. Unhandled errors for the matcher-script.py script arerecorded in the log file but no seed file is created. Unhandled errors for the sensor-script.pyscript are recorded in the log file and displayed in the Discovery Management Console.

• The templates directory and associated files must have the correct access rights. You require readaccess rights to the directory and associated files.

• The sensor that collects the data must complete its discovery with no errors.• The syntax of the matcher and sensor scripts must comply with the version of Jython used, asdefined by the engine-id tag in the template.xml.

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

Sensor name that is used in the GUI and logsGenericComputerSystemSensor

Generic server sensorThe generic server sensor discovers the application servers that are running on a host computer system.

The sensor first discovers listening ports (IP address and ports), established connections, and processesthat are running on targeted computer systems. Templates are used to match runtime processinformation. When specified criteria are matched, the information is used to seed specific applicationsensors, such as the Apache sensor or a custom application server sensor.

The processes can be running on IPv4 or IPv6 addresses. For processes that are running on IPv6 only, theprocesses are discovered, but a seed that starts a more specific sensor is not created.

Custom server templates are used to discover application servers that TADDM does not automaticallycategorize. You can create custom server templates using the Discovery Management Console. If multiplecustom server templates match the application runtime process information, only the first custom servertemplate that is matched causes the custom application server sensor to run.


Sensor name that is used in the GUI and logsGenericServerSensor

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

On Solaris operating systems that support virtualization, from the global zone, the genericserver sensor does not support the discovery of runtime processes in local zones.


• sys.RuntimeProcess

netstat command instead of lsof command for AIX operating systemThe generic server sensor by default uses the netstat command instead of the lsof command on theAIX operating systems. Thanks to this, the LPAR and WPAR processes are separated and WPAR genericsensor is run to discover applications that are installed on WPARs.For details, see “WPAR generic sensor” on page 237.

Asynchronous and script-based discovery supportThe generic server sensor supports asynchronous and script-based discovery.





LimitationsSome function that is provided by the generic server sensor during a nonscript-based discovery is notsupported in an asynchronous or script-based discovery.







com.collation.discover.agent.command.netstat.Windows

You can use this property to specify a custom command to use instead of the netstat -naocommand on a Windows target.

You must ensure that any alternative command you specify returns information in the same format asthe netstat -nao command.

For example,

com.collation.discover.agent.command.netstat.Windows.ip_address=type c:\\\\folder\\\\mynetstat.txt

where mynetstat.txt contains the output of the netstat -nao command, and the typecommand is used to print the contents of the file.

com.collation.netstatoverlsof.AIX=true

This property specifies which command (netstat or lsof) is used to collect the process information onAIX operating systems, and it is applicable mainly for deciding the command to build port map andopen TCP port to process map.

By default, the property is set to true, and netstat command will be used.

If the property is set to false, then lsof command will be used, but in some scenarios, netstatcan be still used, e.g. in case where we need to determine whether the privileges for isof aresufficient or not.

Note: There is a dependency on the commands of netstat and kdb even with false value of thisproperty. Point to note is that netstat gets executed in the OS layer and is a requirement for not onlyGenericServer sensor.

com.collation.discover.agent.useSolarisPfiles=falseThe default value is false.When set to true, this property causes the GenericServerSensor to use the ptree and pfilescommands on Solaris target systems to discover the list of IP sockets and ports that are associatedwith the running processes. The property replaces the use of lsof which might not be available in aSolaris environment.

Troubleshooting the sensorThis topic describes common problems that occur with the generic server sensor and presents solutionsfor those problems.

The generic server sensor does not discover open socketsProblem

The generic server sensor fails to discover open sockets. You might find the following message in theerror logs:

CTJTD2522E Sensor is not able to discover processes pids for open sockets.

SolutionSee the DEBUG-level logs of the sensor to find a detailed reason of this failure. Depending on thereason, complete the following tasks:

• If a command timeout occurred, increase the timeout by setting the value of thecom.collation.discover.agent.command.pidsInfoTimeout property. This property


can be scoped to a specific IP. For example, thecom.collation.discover.agent.command.pidsInfoTimeout.192.168.2.1=1800000 property specifies a 30-minute timeout for the IP 192.168.2.1. Remember to increasetimeout values for the Generic server sensor and the IBM AIX computer system sensor as well.

• If the logs contain either of the following messages:

– "os.AixOs - Unable to get pids for open sockets com.collation.platform.os.OsException: Unable tofind <sctp_pcb_hash_table>" (for a regular discovery),

– "sensor.GenericServerScriptSensor - Unable to find <sctp_pcb_hash_table>" (for a script-baseddiscovery),

apply a fix for APAR IZ98746, IZ98842, IV04783, or IV05965 on a discovered AIX host.• If the logs contain a message similar to the following one:

for i in `netstat -Aan| grep tcp|awk '{print $1}'`;do echo \"sockinfo $itcpcb\"|kdb|grep ACTIVE; echo $i$'\n####';doneopen: Permission deniedf100020000060bb0####open: Permission deniedf10002000004ebb0####...

complete one of the following procedures:

– Install the netstat, sockinfo, and kdb commands. Grant the TADDM user the executionpermissions to run them.

– If you have the kdb command installed, define sudo for it by setting the following property:

com.collation.discover.agent.command.kdb = sudo kdb

– Set the com.collation.netstatoverlsof.AIX property to false to enable the lsofcommand to collect the process information instead of the netstat command.

IBM Tivoli Utilization sensorThe IBM Tivoli Utilization sensor gathers basic metrics from a target system. The sensor uses the TADDMdiscovery infrastructure to deploy scripts that run system-level performance monitoring commands onthe target system. At specified intervals, the sensor gathers data from the target system and provides it tothe TADDM server, where operating system metric objects are created.

The IBM Tivoli Utilization sensor provides metrics and a utilization report. You can use this informationwith the System Connection Topology Report to identify servers that are not used to capacity and do notprovide services to other servers.

Sensor name that is used in the GUI and logsOperatingSystemUtilizationSensor

PrerequisitesFor the sensor to discover a target system, the target system must have the following commands installedin the default location for the respective operating system:

• compress command• netstat command• sadc command• sar command

On target systems that are running the following operating systems, the following respective prerequisitesmust be met:


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

• Solaris

– The compress command must be available.– The netstat command must be available.– The sar command must be available.

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

• 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 andat.allow files.

You must copy the following JAR files to the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.sys.utilization_version/lib directory:

• db2jcc.jar• oracle-jdbc-9.2.jar

LimitationsThe sensor is intended for short-term use (for example, a maximum of one month of use) to analyzeservers and identify consolidation targets. The sensor can be used only for the firewall zone in which theTADDM 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 fordiscovering applications that span firewall zones, use the IBM Tivoli Monitoring product.

Asynchronous and script-based discovery supportThe IBM Tivoli Utilization sensor supports asynchronous and script-based discovery. All function that isprovided by the sensor during a nonscript-based discovery is supported in an asynchronous or script-based discovery.

Sensor configuration requirementsFor asynchronous discovery, first complete the steps that are described in the Configuring forasynchronous discovery topic in the TADDM Administrator's Guide. Before running an asynchronousdiscovery, you must start the Utilization sensor on the target system to collect utilization data. Thediscovery script package that is generated for an asynchronous discovery must be extracted on the targetsystem. After the discovery script package is extracted, complete the following steps:

1. Change to the taddmasd/com.ibm.cdb.discover.sensor.sys.utilization_versiondirectory.

2. Change the file permissions according to the following command:


chmod 700 *.sh

3. To start the Utilization sensor, run the following command:

./utilizationDeployer.sh -c

Specify the time interval and duration for collecting data. Before starting to collect data, you must waituntil after the time interval has elapsed.

4. Periodically collect data by running the taddmasd/scriptsRunner.sh script. This script generatesan 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 thetaddmasd/com.ibm.cdb.discover.sensor.sys.utilization_version directory, and run thefollowing command:

./utilizationDeployer.sh -u

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



Model objects with associated attributesThe IBM Tivoli Utilization sensor creates model objects with associated attributes. The attributes indicatethe type of information that the sensor collects about the utilization of your Computer Systems in your ITenvironment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.metric.OperatingSystemMetric

• Label• MetricName• MetricUnitOfMeasure• MetricValue• StatisticName

net.IpInterface

• IpAddress

relation.Gauges

• Source (OperatingSystemMetric)• Target (OperatingSystem)

The following computer system types are discovered:

sys.aix.AixUnitaryComputerSystemsys.hpux.HpUxUnitaryComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.SunSPARCUnitaryComputerSystem


sys.windows.WindowsComputerSystem

The following attribute is associated with these model objects:

• signature

The following operating system types are discovered:

sys.aix.Aixsys.hpux.HpUxsys.linux.Linuxsys.sun.Solarissys.windows.WindowsOperatingSystem

The following attribute is associated with these model objects:

• OSName

Configuring the sensorBefore running the IBM Tivoli Utilization sensor to gather data from a target machine, you must configurethe sensor.

Setting configuration parametersYou can configure the behavior of the IBM Tivoli Utilization sensor by setting the configurationparameters.

The following table lists the configuration parameters of the IBM Tivoli Utilization sensor.

Table 19. Configuration parameters

Parameter name Description

operatingMode The mode of operation for the sensor. The following values are valid:ONCE

Specifies that the collection scripts run once for the interval and numDays,or maxFileSize, specified, whichever comes first. When the collection scriptshave finished, the data is collected by the sensor the next time that it runs. Thedata collected is parsed and stored on the TADDM database. All output files onthe target machine are cleaned up.

RESTARTSpecifies that when the collection scripts finish as normal, the collection scriptsare started again.

CLEANUPSpecifies that any collection currently running on the system is immediatelystopped and cleaned up. Once a cleanup operation is called, collection can onlybe 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 targetsystem, regardless of whether the collection scripts have completed or not.

ENDSpecifies that data is collected when the sensor is run on the target system,only if the collection scripts have completed. Except in situations whereoperatingMode is set to CLEANUP, any discovery performed before thecollection scripts have completed results in no data collection.

interval The collection interval, in minutes, for collection scripts running on the target. Validvalues are between 3 minutes and 60 minutes.


Table 19. Configuration parameters (continued)

Parameter name Description

numDays The number of days that the collection scripts run on the target. Valid values arebetween 1 day and 35 days.

maxFileSize The maximum size, in MB, for the output files created by the collection scripts.Valid values are between 1 MB and 100 MB.

Configuring cleanup optionsThe IBM Tivoli Utilization sensor has a function that automatically cleans up and removes the collectionscripts and data stored on the target machine. It is also possible to perform the cleanup manually, ifrequired.

Configuring automatic cleanup during discoveryTo use the automatic cleanup function, complete the following steps:

1. Create a profile configuration for the IBM Tivoli Utilization sensor that has the operatingModeparameter set to CLEANUP.

2. Run a discovery using the profile that has the CLEANUP option set.

After the cleanup has been performed on the target discovery machine, to start the collection scriptsagain carry out a RESTART operation.

Performing manual cleanupTo perform a manual cleanup on a UNIX target machine, complete the following steps:

1. Navigate to the /var/tmp/ directory.2. Run the following command:

./scmd_perf.sh -k -c -r

3. Remove the IBM Tivoli Utilization sensor lock file.

To perform a manual cleanup on a Windows target machine, complete the following steps:

1. Navigate to the C:\ directory.2. Remove the WINTEL-MAN-PERF.VBS script.3. Remove the PerformanceData_hostname.out file.4. Remove the IBM Tivoli Utilization sensor lock file.

Configuring the BIRT reportYou can use Utilization BIRT report to generate reports based on the data collected by the IBM TivoliUtilization sensor.

Important: Configuring the Utilization BIRT report is only possible if you have BIRT Report Viewerenabled. BIRT Report Viewer is disabled because of security issues. The alternative way to view the BIRTreports is by using the Tivoli Common Reporting (TCR) after you import the TADDM reports to TCR. If youare aware of the risks, you can restore BIRT Report Viewer.

To see how to restore BIRT Report Viewer, see the Restoring BIRT Report Viewer topic in the TADDMAdministrator's Guide.

The steps 1, 2 and 4 are specific to BIRT Report Viewer. If you are viewing reports by using TCR, you mustspecify values for the parameters as in the step 3.

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:

ScopeFrom the list of available TADDM scopes, select a scope.

MetricFrom the list of available metrics, select the metric for which you want to view data, or select ALLto display data for all metrics.

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

ValueIf you specified an operator, you must specify a corresponding value. Otherwise, select N/A todisplay all data for the selected metric.

Another valueIf you specified an operator, and it requires two values, you must specify a corresponding value forthe second value. Otherwise, select N/A to display all data for the selected metric.

Number of application dependenciesThe 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 selectedmetric.

4. Click OK.The report output is displayed in the BIRT Report Viewer.

To configure the Hourly Peak Server Utilization BIRT report complete the following steps in the DataManagement Portal:

1. Click Analytics > BIRT Reports. The TADDM BIRT Reports window is displayed.2. Select TADDM_SERVER_UTILIZATION_HOURLY_PEAK report and click Run Report.3. In the Parameter window, a value for each of the following parameters must be specified:

ScopeFrom the list of available TADDM scopes, select a scope.

DateFrom the list of available dates, select a date.

4. Click OK. The report output is displayed in the BIRT Report Viewer.

Configuring the discovery profileThe IBM Tivoli Utilization sensor is configured through the use of discovery profiles. A default discoveryprofile, named Utilization Discovery, is provided out of the box. It can be used to perform discoveries as is,or a new profile with customized configuration parameter values can be created.

The out-of-the-box Utilization Discovery profile has the following default property values:

• operatingMode: ONCE• collectionMode: ALWAYS• interval: 15• numDays: 35• maxFileSize: 100

It contains the following default sensors:

• Ping sensor• Port sensor• Session sensor


• Anchor sensor• Operating system utilization sensor

If the default discovery profile is not sufficient for your needs, you can create a profile with customizedconfiguration parameters. To create a customized discovery profile, complete the following steps:

1. In the Discovery drawer of the Discovery Management Console, click Discovery Profiles.2. In the Discovery Profiles window, click New.3. In the Profile Name field, type the name of the new profile.4. In the Description field, type a description of the new profile.5. From the Clone existing profile list, select Utilization Discovery.6. Click OK.7. In the Discovery Profiles window, select the new profile, and on the Sensor Configuration tab,

select the OperatingSystemUtilizationSensor sensor.8. To create a sensor configuration based on the OperatingSystemUtilizationSensor default

configuration, click New. The Create Configuration window is displayed.9. In the Name field, type the name of the new sensor configuration.

10. In the Description field, type a description of the new sensor configuration.11. Click Enable this configuration and disable selected configuration to ensure that this configuration

is used, by default, by the discovery profile.12. For each configuration parameter you want to update, complete the following tasks:

a. In the Configuration section, double click the configuration parameter you want to change.b. Enter a new value for the configuration parameter.

13. Click OK.14. In the Discovery Profiles window, click Save.

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

Discovery using cleanup fails when using non-root credentialsProblem

A Utilization sensor discovery using the CLEANUP option fails for an endpoint when using non-rootcredentials.

SolutionIf the endpoint was last discovered by a TADDM server using root credentials, the Utilization sensorscripts deployed to /var/temp have root system access. These scripts cannot be removed by thenon-root user ID. To ensure that the cleanup completes correctly, run the Utilization sensor discovery,using the CLEANUP option, on that endpoint, using root credentials. Any existing Utilization sensorscripts are removed.

Metrics data not discovered from a target machine when running an asynchronousdiscoveryProblem

An asynchronous discovery is run, but the IBM Tivoli Utilization sensor does not discover metrics dataon the Solaris operating system.

SolutionYou must start the IBM Tivoli Utilization sensor from the extracted script package on the targetsystem.


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

Sensor name that is used in the GUI and logsIpDeviceSensor


• net.IpInterface• sys.ComputerSystem

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

com.ibm.cdb.topomgr.reconciliation.compsys.CompSysReconcilatior.disableLMTupdate=false

Specifies whether to update the last modified time of a computer system that is discovered by the IPdevice sensor, when such computer system exists in the TADDM database and was discovered byother sensors.

To disable the last modified time update, set this property to true. By default, this property is set tofalse.

IP interface sensorThe IP interface sensor discovers IP interfaces.

Sensor name that is used in the GUI and logsIpInterfaceSensor

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


• net.IpInterface• net.IpV4Router• net.IpV6Router• sys.ComputerSystem


Ping sensorThe ping sensor discovers reachable IP addresses. It gathers information from devices and systems thatsupport TCP/IP.

Sensor name that is used in the GUI and logsPingSensor

Limitations• Because of the performance issues, when discovering ping over UDP, the Ping sensor always uses alldefined SNMPv1 and SNMPv3 access list entries, regardless of their scope restrictions.


Configuring the discovery profileYou can configure PingSensor to start a session on IP addresses that are accessible through OSLC ExecuteAutomation session.

The behavior for target systems that are accessible through OSLC Execute Automation session can bechanged by setting the following property:

com.ibm.cdb.discovery.StartOSLCSessionDirectly

If the property is set to true, the sensor does not ping the ports and the target systems that areaccessible through OSLC Execute Automation session are not scanned. The Session sensor is starteddirectly after PingSensor for such systems.

If the property is set to false, PingSensor pings all target systems.

The default value of the property is true.

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

com.collation.discover.agent.PingSensor.timeout=600000This value specifies the time interval in milliseconds before a timeout occurs during a discovery.

com.collation.pingagent.ports=xx,yy,...This property is not defined in the collation.properties file and must be manually added ifneeded. Valid values are non-negative numbers that represent ports for the ping sensor to use.

By default, the ping sensor uses port 22, and if it cannot make a connection to port 22, it uses port135. To override the default set of the TCP ports that the ping sensor uses, add this property to thecollation.properties file, and specify the TCP port numbers as a comma-separated list.

com.ibm.cdb.discover.enablePingDiscoveryOverUdp=falseIf set to true, the sensor runs additional ping over UDP.You can also access the property through the Product Console Platform Properties tab for customizeddiscovery profiles.

Restriction: The scope restrictions for this property are not supported.

com.ibm.cdb.discover.pingUDPPorts=161The valid values are non-negative numbers.This property specifies which ports are to be scanned during the UDP ping discover. By default, thePing sensor uses port 161. You can also access the property through the Product Console PlatformProperties tab for customized discovery profiles.

Restriction: The scope restrictions for this property are not supported.


com.ibm.cdb.discover.SNMPPingWaitTime=2000This property specifies the time value (in milliseconds) for the Ping sensor to wait for a single pingrequest sent via the SNMP protocol with a specific SNMP authentication credentials.

Troubleshooting the sensorThis topic describes common problems that occur with the Ping sensor and presents solutions for thoseproblems.

Ping sensor discovery ends with an unable to establish loopback connectionmessageProblem

The sensor fails when the scope of discovery is large, due to a timeout error, and the followingmessage is displayed:Unable to establish loopback connection

View the log file for a detailed description of the message, for example:

<log start>java.io.IOException: Unable to establish loopback connectionat sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:172)at java.security.AccessController.doPrivileged(AccessController.java:246)at sun.nio.ch.PipeImpl.<init>(PipeImpl.java:188)at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:45)at java.nio.channels.Pipe.open(Pipe.java:148)at sun.nio.ch.WindowsSelectorImpl.<init>(WindowsSelectorImpl.java:192)at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:53)at java.nio.channels.Selector.open(Selector.java:224)at com.collation.platform.session.Ping$Connector.<init>(Ping.java:303)at com.collation.platform.session.Ping.pingArray(Ping.java:656)at com.collation.platform.session.Ping.pingLoop(Ping.java:574)at com.collation.platform.session.Ping.ping(Ping.java:557)at com.ibm.cdb.discover.sensor.net.ping.PingSensor.do_ping(PingSensor.java:75)at com.ibm.cdb.discover.sensor.net.ping.PingSensor.discover(PingSensor.java:92)at com.collation.discover.engine.AgentRunner.run(AgentRunner.java:214)at com.collation.discover.engine.DiscoverEngine.processWorkItem(DiscoverEngine.java:1184)at com.collation.discover.engine.DiscoverEngine$DiscoverWorker.run(DiscoverEngine.java:867)Caused by: java.nio.channels.ClosedByInterruptExceptionat java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:216)at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:543)at java.nio.channels.SocketChannel.open(SocketChannel.java:161)at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:120)... 16 more<log end>

SolutionUse one of the following methods to resolve the problems:

• Perform the discovery on a smaller scope.• In the collation.properties file, increase the timeout value for a longer discover time for the

following property:

com.collation.discover.agent.PingSensor.timeout=600000

Ping sensor discovery ends with error CTJTD0510EProblem

If you enable the ping discovery over UDP, it is possible that, when discovering large scopes, thesensor ends with the following error because it exceeds the limit of open sockets:CTJTD0510E The following error occurred in the ping sensor: Too many open files.


View the log file for a detailed description of the message, for example:

<log start>sensor.PingSensor - Exception in Ping Broadcast Agentjava.io.IOException: Too many open files at sun.nio.ch.IOUtil.makePipe(Native Method) at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:77) at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:48) at java.nio.channels.Selector.open(Selector.java:238) at com.collation.platform.session.Ping$TcpConnector.<init>(Ping.java:354) at com.collation.platform.session.Ping$TcpConnector.<init>(Ping.java:349) at com.collation.platform.session.Ping.pingArray(Ping.java:926) at com.collation.platform.session.Ping.pingLoop(Ping.java:840) at com.collation.platform.session.Ping.ping(Ping.java:821) at com.ibm.cdb.discover.net.ping.sensor.PingSensor.do_ping(PingSensor.java:81) at com.ibm.cdb.discover.net.ping.sensor.PingSensor.discover(PingSensor.java:114) at com.collation.discover.engine.AgentRunner.doRegularDiscovery(AgentRunner.java:349) at com.collation.discover.engine.AgentRunner.run(AgentRunner.java:271) at com.collation.discover.engine.DiscoverEngine.processWorkItem(DiscoverEngine.java:736) at com.collation.discover.engine.worker.DiscoverWorker.processWorkItemWithMetrics(DiscoverWorker.java:100) at com.collation.discover.engine.worker.DiscoverWorker.run(DiscoverWorker.java:146)2012-09-12 16:48:29,076 DiscoverManager [DiscoverWorker-5] PingSensor-9.156.46.6˜9.156.46.254 WARN engine.AgentRunner - [AgentRunner.W.1] AgentException thrown in agentcom.collation.discover.agent.AgentException: CTJTD0510E The following error occurred in the ping sensor: Too many open files .<log end>


• Perform the discovery on a smaller scope.• On UNIX systems, increase the open file limit on the discovery server. For more information about

the open file limit, see TADDM server software requirements.

Ping sensor fails with a timeout errorProblem

For large scopes, the sensor fails with a timeout error.All the actions of the Ping sensor that are visible in UI are run in a sequence. The timeout value that isspecified in the collation.properties file defines the total time that is needed to finish thoseactions.


• Perform the discovery on a smaller scope.• In the collation.properties file, increase the timeout value for a longer discover time for the

following property:

com.collation.discover.agent.PingSensor.timeout=600000

The sensor does not discover endpoints over the UDP protocolProblem

When discovering endpoints that are accessible only over the UDP protocol, some of them aremissing.

SolutionYou must configure the properties that are responsible for the discovery over the UDP protocol. Formore information about those properties, see Configuring the collation.properties file.To retrieve information about open UDP ports, the Ping sensor uses the SNMP protocol to query thediscovery endpoints. Make sure that the proper SNMP or SNMPv3 authentication credentials areprovided in the TADDM access list. You can also verify if your firewall passes the network trafficthrough the ports that are specified in the com.ibm.cdb.discover.pingUDPPorts property.


Port sensorThe port sensor discovers open ports on a host system.

You can change certain aspects of the port sensor using the sensor configuration file. You must create acustom discovery profile to change the port sensor configuration. Before changing the configuration file,contact IBM Software Support.

Sensor name that is used in the GUI and logsPortSensor

Troubleshooting the sensorThis topic describes common problems that occur with the Port sensor and presents solutions for thoseproblems.

The sensor does not discover any open UDP portsProblem

When discovering the endpoint ports, the sensor does not find any open UDP ports.Solution

You must configure the properties that are responsible for the discovery over the UDP protocol. Formore information about those properties, see Configuring the collation.properties file. The Ping sensorand the Port sensor use the same properties for discovery over the UDP protocol.To retrieve information about open UDP ports, the Port sensor uses the SNMP protocol to query thediscovery endpoints. Make sure that the proper SNMP or SNMPv3 authentication credentials areprovided in the TADDM access list. You can also verify if your firewall passes the network trafficthrough the ports that are specified in the com.ibm.cdb.discover.pingUDPPorts property.

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

Sensor name that is used in the GUI and logsSessionSensor

Configuring the access listAccess list entries with type Computer System are tried sequentially until a session is established. ForWindows targets, access list entries with type Computer System (Windows) are used.

TroubleshootingThis topic describes common problems that occur with the session sensor and presents solutions forthose problems.

CTJTD0591W Session IP not found within discovered IP interfaces

ProblemThe IP being discovered does not actually exist in the interface list of the object.Usually this means the object being discovered is a load balancer. Discovering load balancers can leadto over-merges. For example, if you have three computers behind the load balancer, the ssh requests


from the sensor may go to different targets each time. This would result in all three computersmerging over time.

SolutionA new property has been added to the session sensor:com.collation.discover.agent.sys.SessionSensor.loadBalancerIpThe default is false.If set to true, then this property stops the session sensor if it senses this condition.

Note: After the failure of the session sensor, the SnmpSensor will not be triggered either.

Sensors fails with access denied error messageProblem

During a discovery of Windows Server 2012 with User Account Control turned on, the following errormessage is displayed:

CTJTP1163E The following WMI session and SSH sessions cannot be established (WMI: SELECT BuildVersion FROM Win32_WMISetting failed: Access is denied.

SolutionThis message indicates that User Account Control settings are too restrictive. To fix the problem,complete the following steps:

1. On the target machine, run the Registry Editor, Regedit.exe.2. Set the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System LocalAccountTokenFilterPolicy value to 1.

3. In the Control Panel window, click the Administrative Tools tab and open Local Security Policy.4. Expand Local Policies and click Security Options.5. Change the following policies:



In order to configure policies on the system with Active Directory, complete the following steps:

1. In the Control Panel window, click the Administrative Tools tab and open Group PolicyManagement.

2. Choose forest and domain and select Default Domain Policy.3. Click Action > Edit.4. Open Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security options.

5. Change the following policies:



SSH discovery of Windows target with Tectia SSH Server fails with the invalidvirtual path errorProblem

The SSH discovery of a Windows system fails, and the log files contain the following message:

java.io.IOException: SSHSCP1.readResponse, error: scp: invalid virtual path


SolutionTectia SSH Server supports virtual folders. It is possible to remove all default virtual folders named C:,D:, E:, and so on, and to define virtual folders named C, D, E, and so on. In such case, full paths withcolons in name, for example /C:/folder/example.txt, are not accepted by the server. To solvethis problem, complete one of the following steps:

• Modify Tectia SSH Server configuration by defining virtual folders with colons.• Add the following scoped property to the collation.properties file:

com.ibm.cdb.session.tectia.filepath.removeColon=true

You can define the preceding flag only for the selected IPs and scope sets. For example:

com.ibm.cdb.session.tectia.filepath.removeColon.10.11.12.13=truecom.ibm.cdb.session.tectia.filepath.removeColon.scopesetA=true

The application cannot establish the WMI sessionProblem

The following warning message can be found in the SessionSensor logs:

SessionSensor-10.4.112.196-[445,135] WARN engine.AgentRunner -[AgentRunner.W.1] AgentException thrown in agentcom.collation.discover.agent.AgentException: CTJTP1161E The applicationcannot establish the following WMI session: SessionClientException:Uncaught exception invoking InstallProvider: System.NullReferenceException: Object reference not set to an instance of anobject.

SolutionTo define the cause of the problem, complete the following steps:

1. Test WMI locally by running simple queries, to see whether it returns any data.2. Run the following WMI verifyrepository command:

Winmgmt /verifyrepository

If simple queries do not return any results, or if the verifyrepository command is corrupted, thecause of the problem is WMI repository. If the verifyrepository command fails, a local serveradministrator must rebuild the local WMI repository or recompile it completely from files on theserver. If it does not resolve the problem, further investigation is necessary.

"The RPC server is unavailable" error occurs during discovery with the sessionsensorProblem

When you run a discovery by using the session sensor, the following error occurs:

The RPC server is unavailable. (Exception from HRESULT:0x800706BA>

SolutionCheck whether the reverse DNS lookup function works properly for the failing target. Run the followingcommand from the TADDM discovery server, or the anchor server:

nslookup target-IP-address

Check if the IP address of the target is correctly mapped to its FQDN name.


Configuring the collation.properties file entriesYou can configure the session sensor by modifying the collation.properties file entries

com.collation.discover.agent.sys.SessionSensor.timeout.snmp=falseThis property specifies whether SNMP MIB2 sensor starts after the session sensor times out.The default value is false.By default, when the session sensor times out, the SNMP MIB2 sensor is not started. At the sametime, when the session sensor fails for other reason than a timeout, or the CTJTD0591W error, theSNMP MIB2 sensor is started. If you want the SNMP MIB2 sensor to be started also when the sessionsensor times out, set the value of this property to true.

com.collation.discover.agent.sys.SessionSensor.loadBalancerIp=falseThis property specifies whether the session sensor is stopped when the discovered object is a loadbalancer.The default value is false, which means that the sensor is not stopped.Discovering load balancers might lead to over merges. If the error "CTJTD0591W Session IP not foundwithin discovered IP interfaces" occurs, change the value of this property to true.

Note: When this property is set to true, and the session sensor is stopped, the SNMP MIB2 sensor isnot started.

Solaris zones generic sensorThe Solaris zones generic sensor discovers applications running on Solaris local zone systems.

The sensor results are used to start specific application sensors, such as IplanetServerSensor,WeblogicServerSensor, or CustomServerSensor, which discover application servers that TADDM does notautomatically categorize.

This sensor uses a discovery approach that is different from other UNIX systems. Rather than running adiscovery against local zone systems directly, a global zone system is used to start theZonesGenericSensor. The discovery of applications on local zone requires the ZonesGenericSensor to run.To retrieve all operating system details of the local zone, you must include the IP address of the local zonein the discovery scope.

Sensor name that is used in the GUI and logsZonesGenericSensor

PrerequisitesThe credentials for local and global zones must be entered in the access list (either using SSH key-basedauthentication or SSH login-based authentication).

Security issuesTo correctly discover applications running on a local zone, the TADDM service account in the local andglobal 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. Modifythe following properties in the $COLLATION_HOME/etc/collation.properties file to configure theps command to use sudo:

• 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.psUsers.SunOS=sudo /usr/ucb/ps auxw


LimitationsNote the following limitations:

• The sensor does not create ProcessFileSystemMapping objects for local zones. When a process runningon a local zone uses an NFS share, the dependency between the application server and the NFS Serveris not created.

• When WebLogic 8 (all releases) managed and admin servers are running on local zones, the runtimeinformation is stored using the CustomAppServerSensor. The CustomAppServerSensor is started by theWeblogicVersionSensor. 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 WebLogiccommand line and that the custom server is enabled.

• When running a discovery through an anchor server, include the IP addresses of the local and globalzones in the same scope set as the anchor.

• Internet Protocol version 6 (IPv6) is not supported when running a discovery on a local zone.



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

Solaris zones generic sensor is not started because of an incorrect IP address of azoneProblem

Solaris zones generic sensor is not started. In the error log files, you can find the information that azone has an incorrect IP address. The logs indicate that the IP address is generated by the hostzoneName command.

Solution

If you use TADDM 7.3.0.2, or later, go to the collation.properties file, and set thecom.collation.hostnameforzoneip property to false.

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

In addition to Nmap, discovery sensor can use Tivoli Remote Execution and Access (RXA) for Windowsdiscovery. It can discover MAC address of L2Interface.

Sensor name that is used in the GUI and logsStackScanSensor

PrerequisitesThe sensor requires the following software:

• Nmap tool. See “Configuring Nmap” on page 232 for details.• 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.• Sudo tool for non-Windows operating systems.


For TADDM on AIX operating systems: For the TADDM user to use the nmap tool through sudo, youmust install and configure sudo version 1.6.7p5. This is because TADDM has problems with the mostrecent sudo version, which is version 1.6.9p15.

Security issuesTo configure sudo access for the TADDM user, you need to set a nopasswd option in the /etc/sudoersfile for the TADDM user.

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

nmap -T Normal -O -sS -sU -oX - IPaddress

Application servers and services discovered using a credential-less (Level 1) discovery are reconciled withthe application servers and services using a Level 2 or Level 3 discovery, only if the binding TCP ports arethe same. All application servers and services discovered using a Level 1 discovery remain following aLevel 2 or Level 3 discovery, but applications and services matching on the binding ports are merged.


• net.IpAddress• net.IpInterface• net.L2Interface• sys.aix.Aix• sys.aix.AixUnitaryComputerSystem• sys.ComputerSystem• sys.hpux.HpUx• sys.hpux.HpUxUnitaryComputerSystem• sys.i5OS.I5OperatingSystem• sys.linux.Linux• sys.linux.LinuxUnitaryComputerSystem• sys.OperatingSystem• sys.sun.Solaris• sys.sun.SunSPARCUnitaryComputerSystem• sys.tru64.Tru64• sys.windows.WindowsComputerSystem• sys.windows.WindowsOperatingSystem• sys.zOS.ZOS• sys.zOS.ZSeriesComputerSystem


Configuring the sensorBefore running a discovery of the installed operating system and open ports, you must configure the StackScan sensor.

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

Installing NmapBefore installing Nmap for any operating system, see the TADDM support site at https://www-947.ibm.com/support/entry/portal/product/tivoli/tivoli_application_dependency_discovery_manager?productContext=267282604 for recent news aboutyour specific operating system and Nmap versions.

Nmap is not installed during the TADDM installation. The Nmap tool is available on TADDM DVD #2, andyou must install it manually. Install Nmap on the TADDM server and all anchor servers. For moreinformation, see the readme file in the Nmap directory on the DVD.

Configuring root authorityFor non-Windows platforms, give root authority for all commands to the TADDM user ID that starts theTADDM server.

If you are using a TADDM anchor server, give root authority to the discovery service account on the anchorserver.

As root user, add the following line in the /etc/sudoers configuration file, using the visudo command:

TADDM_userid ALL=(ALL) NOPASSWD:ALL

where

• TADDM_userid is the user ID that starts the TADDM server, or the discovery service account on ananchor.

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 executionpermission only for the Nmap command. Add the following line in the /etc/sudoers configuration file:

TADDM_userid ALL=(ALL) NOPASSWD:nmap_path

where

• TADDM_userid is the user ID that starts the TADDM server, or the discovery service account on ananchor.

• nmap_path is the full path to the location of the nmap command.

If the sudoers file contains a Defaults requiretty line, comment it out or delete the line.

Configuring the Path environment variableNmap must be installed on your TADDM server and on all anchor servers. The Nmap command must be inthe $PATH environment variable for the TADDM user ID that starts the TADDM server. If you are using aTADDM anchor server, the Nmap command must be in the $PATH environment variable for the discoveryservice account.

On Windows platforms, take the following steps to set the Path system environment variable to includethe directory where Nmap is installed:

1. Click Start > Control Panel > System2. Click the Advanced tab, and select Environment Variables.


https://www-947.ibm.com/support/entry/portal/product/tivoli/tivoli_application_dependency_discovery_manager?productContext=267282604



3. Edit the Path system variable and add the directory where Nmap is installed.4. Restart the computer.

This task makes Nmap available to services on the computer.

Verifying that Nmap is workingTo verify that Nmap is working complete the following steps:

1. Log in to the system using one of the following TADDM user IDs:

• The user ID that starts the TADDM server.• The user ID that starts the discovery service account on the anchor server.


sudo nmap -T Normal -O -sS -oX - IPaddress/32

where

• 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 computersystem.

LimitationBecause of a limitation on AIX, only four active Nmap commands can be run at the same instance. Toensure 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:

• nmapMaxOsScanTreads• nmapMaxPingScanTreads

4. To save the configuration, click OK.5. To save the discovery profile, click Save. Use this discovery profile for StackScan discoveries.6. If the number of computer systems in the scope being discovered exceeds 2048, set the following

property in the collation.properties file:

com.collation.discover.dwcount=4

Configuring the discovery profileIf you want to create application servers based on the active TCP/IP ports discovered, update thediscovery profile for the Stack Scan sensor.

To configure the sensor to create application servers, complete the following steps:

1. Create a new discovery profile based on a TADDM Level 1 profile.2. Create a new sensor configuration in the new profile based on the Stack Scan sensor configuration.3. In the new sensor configuration, set the enableNmapPortApplicationCreation property to true.

To configure the sensor to use winscanner, complete the following steps:

1. Create a new discovery profile based on a TADDM Level 1 profile.2. Create a new sensor configuration in the new profile based on the Stack Scan sensor configuration.3. In the new sensor configuration, set the scanners property to nmap,winscanner.


You can further configure which application servers are to be created based on the discovered ports usingthe PortAppScanSensor.properties file located in the osgi\plugins\com.ibm.cdb.discover.sensor.idd.stackscan_7.5.4\etc directory. Specific instructions formodifying the association between ports and application servers appear at the top of thePortAppScanSensor.properties file.

Configuration errors in the PortAppScanSensor.properties file are reported in thePortAppScanSensor.errors file, located in the osgi\plugins\com.ibm.cdb.discover.sensor.idd.stackscan_7.5.4\etc directory.

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

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

com.collation.sudoCommand=sudoThis value specifies the sudo location.

com.collation.discover.agent.StackScanSensor.timeout=7200000This value specifies the time interval in milliseconds before a timeout occurs during a discovery.

Troubleshooting the sensorThis topic describes common problems that occur with the Stack Scan sensor and presents solutions forthose problems.

The Stack Scan sensor completes successfully, but no Computer Systems are storedProblem

Doing a Level 1 discovery, the Stack Scan sensor finishes without errors, but it does not store anycomputer system information. In the services/DiscoveryManager.log, you see the followingmessage:

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 thensudo "nmap -0 10.1.2.3

Solution

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

The Stack Scan sensor does not discover Computer Systems on a Linux systemProblem

On a Linux server, when performing a Level 1 discovery, the Stack Scan sensor completessuccessfully, 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 thecommand line.

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

The network configuration on Linux for System z systems does not create packetsthat Nmap can readLinux for System z supports both OSA and VSWICH network interfaces operating in Layer 3 (NetworkLayer) or Layer 2 (Link Layer) mode. If operating in Layer 2 mode, TCP packets contain a valid ethernetLink Layer header required by Nmap. However, systems using OSA or VSWITCH operating in Layer 3 moderequire 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 operatewith Layer 3 network interfaces.

For more information about OSA and VSWITCH and their operating modes, see Chapter 7 "qeth devicedriver for OSA-Express (QDIO) and HiperSockets" in the Linux on System z Device Drivers, Features, andCommands at: http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/lk31dd03.pdf.

ProblemThe network configuration on Linux for System z systems does not create packets that Nmap canread.

The Stack Scan sensor uses Nmap to gather data about the targets for credential-less discovery. IfNmap 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 Scansensor 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 followingmessage is displayed:Note: Host seems down. If it is really up,but blocking our ping probes, try -P0...

SolutionDepending on your operating system, perform the following actions:On SUSE Linux for System z 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 nameof the file changes. Contact your system administrator for the name of the configuration file thatyour system uses.

The configuration file must be in the /etc/sysconfig/hardware directory. The file name mightbe hwcfg-qeth-bus-ccw-0.0.5000.

On RedHat Linux for System z systemsThe network must run with the following option:

OPTIONS='fake_ll=1'

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

The configuration file must be in the /etc/sysconfig/network-scripts directory. The filename might be ifcfg-eth0.

Verify that the alias in the /etc/modprobe.conf file includes the following information:

alias eth0 qeth


http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/lk31dd03.pdf

Computer system displays in the incorrect categoryProblem

The computer system displays under the OtherComputerSystem category.Solution

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

Need enhanced Stack Scan sensor debuggingProblem

Need to enable enhanced debugging of the Stack Scan sensor.Solution


1. Check the local-anchor-<machine>.log file to see if Nmap was used by the sensor.2. Enable further debugging by doing the following:

In the collation.properties file, set one of the following:

• com.collation.log.level.StackScanSensor=TRACE• com.collation.log.StackScanSensor=TRACE• com.collation.log.level=TRACE

This method produces a verbose trace of what the sensor is doing, the results, the configurationsused, and more.

Stack Scan sensor fails with a message: sudo: sorry, you must have a tty to run sudoProblem

During a discovery, if the Discovery Management Console where the TADDM server was started isclosed, the sensor fails. The message: sudo:sorry, you must have a tty to run sudo isdisplayed. 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 fileon the TADDM server.

Stack Scan sensor is unable to run the sudo nmap commandProblem

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

SolutionThis problem occurs when the system is configured not to allow the root user to run the sudocommand. To fix the problem, edit the collation.properties file and set thecom.ibm.cdb.discover.sensor.idd.stackscan.alwaysUseLocalAnchor property to true. Then restart theTADDM server.

The Stack Scan sensor does not discover Computer Systems on an AIX systemProblem

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.

SolutionCreate a discovery profile or edit an existing profile for the Stack Scan sensor. In the Configurationsection of the Create Configuration window, click nmapExec. Then double-click the Value field in therow, and append -d to the value nmap. For example, the new value is nmap -d.

After you enable winscanner some of the discovered ComputerSystems have thesignature with no MAC address.Problem

A custom Level 1 discovery is run with only the nmap scanner enabled. Then, another discovery is runon the same scope with both nmap and winscanner enabled. Discovered computer systems havesignatures with no MAC addresses.

SolutionThe Stack Scan sensor stores information only about those target systems that are not discovered yet.Computer systems that are already present in the TADDM database are not updated. Delete thecomputer systems manually and run discovery again.

Stack Scan sensor never updates CI objects already stored into TADDM DB duringLevel 1 discoveryProblem

During a Level 1 discovery, the Stack Scan sensor stores information exclusively (bold) for those newIP objects systems that are not discovered yet and this is as per the way the Level 1 Discovery isdesigned in TADDM. Thus, the CI Computer systems that are already present in the TADDM database,are not updated by the StackScan sensor in case of any changes. Until now, the only possible actionfor TADDM to be able to update the stored CI objects, that were discovered and stored as fake"shallow" objects initially during first time Level 1 discovery is to delete the computer systemsmanually and then run the discovery again, or even run a Level 3 discovery.

SolutionA new feature has been introduced into FP4 to avoid the TADDM creation of fake "shallow" objectsthat usually occurs when you got pingable IP addresses without a corresponding system (creation oflow OS confidence shallow ComputerSystems).

com.ibm.idd.stackscanner.confidence.skip=default 0

WPAR generic sensorThe WPAR generic sensor discovers applications that run on WPAR systems.

The sensor results are used to start specific application sensors, such as JBossSensor, WebSphereSensor, and so on.

The discovery process of this sensor is different than of other UNIX systems. Rather than running adiscovery against WPAR systems directly, an LPAR system is used to start the WPARGenericSensor. This isbecause the kdb command is unavailable on WPARs and the sensor is not able to convert open sockets toprocess PIDs. The whole discovery process is based on the netstat command. The lsof command isnot used.

Sensor name that is used in the GUI and logsWPARGenericSensor


PrerequisitesYou must add the credentials for LPAR and WPAR to the access list.

LimitationsThe sensor does not create ProcessFileSystemMapping objects for LPAR and WPARs.



zEnterprise sensorTo discover the zEnterprise environment, the sensor uses the Enterprise Common Collector (ECC). TheECC is a single entry point for querying all inventory data about the zEnterprise components, bothhardware and software.

The TADDM zEnterprise sensor establishes a secure connection with the ECC and gathers all necessarydata to create a tree of CDM objects. Then, the sensor stores them into TADDM and thus no entry intoeach of the components is necessary. The ECC is a web application that is deployed on a web server.Therefore, the zEnterprise sensor depends on the Port sensor to identify the port that the ECC listens on.The zEnterprise sensor stores objects that describe the physical and virtual structure of zEnterprise,zBladeExtension, and computer systems.

If you want to discover a virtual computer system, you must install and start the Guest PlatformManagement Provider agents that deliver information about the operating systems to the ECC.

The sensor stores the following objects that describe the physical, virtual, and logical components:

• zEnterprise: physical packages, appliances• zEnterprise BladeCenter Extension: BladeCenters, chasises, racks, blades• Computer systems: System z, z/VM® LPARs, PR/SM LPARs• Logical Components: Ensemble, Workload Resource Groups• Virtual Components: Virtual Servers, Virtual Networks, Virtual Storage Resources

Note: For virtual computer systems, the objects are placeholders.

Sensor name that is used in the GUI and logscom.ibm.cdb.discover.sensor.sys.zenterprise_1.0.0.

PrerequisitesFor the zEnterprise discoveries, ensure that the following prerequisites are met:

• The Enterprise Common Collector (ECC) version 1.1.0.2

The ECC is shipped as a distinct component. You must install and configure it separately. However, thesensor can use an ECC instance that is already installed and configured for use by another application,such as the zEnterprise Monitoring Agent shipped with IBM Tivoli Monitoring. For more informationabout installing and configuring the ECC, see the Enterprise Common Collector Configuration Guide andReference.

• The Guest Platform Management Provider agents

You must install, configure, and run the GPMP agents on each of the virtual computer systems. Withoutthose agents, the sensor is unable to detect the operating system and the unique identification of thediscovered computer systems.


Security issuesThe zEnterprise sensor needs an IP address and port to communicate with the ECC. This information isrequired because the sensor calls the ECC RESTful API, receives the data, and then puts it into a dataobject structure which is then passed to TADDM to be stored.

LimitationsVirtual computer systems

Reconciliation of objects that are stored by the zEnterprise sensor and operating system sensors, suchas the Linux computer system sensor, AIX computer system sensor, and Windows computer systemsensor, is not always possible because there are cases when the ECC cannot recognize the type of avirtual computer system or its identification data if a Guest Platform Management Provider agent isnot running there.By default, the sensor stores only known virtual computer systems with correct identification set. Anyvirtual computer system that does not fulfill this requirement is skipped and an appropriate warningmessage is displayed.You can, however, enable storing all discovered virtual computer systems, even the ones of anunknown type. Such computer systems are visible in the Other Computer Systems section. Ifpossible, reconciliation matches the MAC address from the unknown computer system that isdiscovered by the zEnterprise sensor with the L2Interfaces MAC addresses of the computer systemsdiscovered by the platform sensors, and merges them. To make the computer systems mergeautomatically, you must first run the platform sensors, and then the zEnterprise sensor. The reversesequence of discovery, that is launching the zEnterprise sensor first, does not assure the automaticmerging.

LPARsBefore you discover the zEnterprise environment with the zEnterprise sensor for the first time, check ifany previously discovered LPARs became a part of the zEnterprise environment, and thus are visiblethrough System z Hardware Management Console or the ECC. In such case, run a discovery of thoseLPARs with the Linux computer system sensor to avoid duplicates.

Sharing a common ECC instance among multiple applicationsThe Enterprise Common Collector is a common component that is designed to be used by multipleapplications and thus it is possible to have a single ECC instance that serves multiple IBM products. If youwant to share an ECC instance, you must ensure that its version is compatible with those of otherapplications.

Each version of the ECC has an API major version and an API minor version that is associated with it. Youcannot connect an instance of an application, such as the zEnterprise sensor, with an ECC instance thatdoes not have a compatible API version. In such a situation, an error message shows both the detectedand the expected API versions.

The zEnterprise sensor version 1.0.0 requires:

• The ECC API major version 1• The ECC API minor version 2 or higher

1. Use the following URL to determine the API major and minor versions of an ECC instance. You canenter the URL into a web browser of any system that has a network connection to the system that theECC is installed on:

https://ecc_hostname:ecc_port_number/eccapi/version

By default, the port number is 8443.2. Continue to the website even if it displays a warning that the certificate was not issued by a trusted

certificate authority.


3. Determine the api-major-version and api-minor-version from a JSON or XML string from thewebsite. The following is an example of this string:

{ "class":"ecc-version", "self":"/eccapi/version", "name":"ECC version", "description":"Information about the ECC and ECC API version", "api-major-version":1, "api-minor-version":2, "ecc-version":"1.1"}

4. Depending on the API major and minor versions, complete one of the following actions:

• Major version is 1, minor version is 1. This version of the ECC is incompatible with the zEnterprisesensor. You must upgrade the ECC to version 1.1.0.2, which is provided with TADDM. For moreinformation about upgrading the ECC, see the Enterprise Common Collector Configuration Guide andReference.

Note: After upgrading the ECC, you might need to upgrade other applications, such as zEnterpriseMonitoring Agent of IBM Tivoli Monitoring, that use the ECC.

• Major version is 1, minor version is 2 or higher. This version of the ECC is compatible with thezEnterprise sensor. You can use both the sensor and the ECC.

• Major version is 2 or higher: This version of the ECC is incompatible with the zEnterprise sensor. Youcan use this instance of the ECC, but you must upgrade the zEnterprise sensor to a newer version.

Model objects with associated attributesThe zEnterprise sensor creates model objects with associated attributes. The attributes indicate the typeof information that the sensor collects about the zEnterprise environment.

The sensor creates the following model objects:Hardware Management Console (HMC) application (Console)

• phys.physpkg.PhysicalPackage• sys.appliance.Appliance• sys.zOS.ZHMC• sys.OperatingSystem• net.L2Interface• net.IpV4Address• net.IpV6Address• net.IpInterface• net.IpNetwork

Ensemble

• core.Ensemble

Central Processor Complex (CPC)

• phys.physpkg.PhysicalPackage• sys.zOS.ZSeriesComputerSystem

zEnterprise BladeCenter Extension (zBX)

• sys.zOS.ZBXFeature

Rack

• phys.physpkg.Rack


BladeCenter

• phys.physpkg.Chassis• sys.ComputerSystem

Blade

• phys.physconn.Slot• phys.physpkg.Board• sys.ComputerSystem• sys.appliance.SmartAnalyticsOptimizer• sys.appliance.DataPower• sys.OperatingSystem• net.L2Interface• net.IpV4Address• net.IpV6Address• net.IpInterface• net.IpNetwork

zVM Virtualization Host

• sys.zOS.ZVM

Virtual Server

• sys.ComputerSystem• sys.zOS.ZVMGuest• sys.OperatingSystem• net.L2Interface• sys.zOS.ChannelSubSystem

Logical Partition (LPAR)

• sys.zOS.LPAR• sys.OperatingSystem

Virtual Network

• net.Vlan

Workload Resource Group

• sys.zOS.WorkoadResourceGroup• service.ServiceInfrastructurePerformancePolicy• service.ServiceInfrastructureServiceClass

Virtualization Host Storage Resource

• dev.StorageVolume


The following configurations are required:

• Access list entry with user ID and password for the ECC, and certificate for HTTPS• The zEnterprise sensor discovery configuration• Scope


The following configurations are optional:

• Timeout configuration• Full discovery configuration

Configuring the access listUse the following access details to configure the access list.

Before querying the restful API, the sensor must authenticate with the ECC by using a user name, apassword, and certificate. Those credentials are supplied to TADDM by using a new component type inAccess List: Data Collectors. One of the supplied entries in the access details is a truststore with the ECCcertificate.

The sensor uses the truststore to establish a secure, encrypted session with the ECC. It is created withthe use of keytool, the Java key, and certificate management utility. Any computer system that has Javainstalled can be used to create such truststore. If such a computer system is not available, use the JavaRuntime Environment (JRE) that is installed with the ECC.

You can find the ECC certificate in the following location, where key_alias is the key alias that is specifiedduring ECC installation:

ecc_install_path/certificates/key_alias.cert

1. To create the truststore and import the certificate, run the following command. Enter the command onone line.

jre_path/bin/keytool -import -noprompt -alias key_alias -file certificate_path/key_alias.cert -keystore truststore_name -storepass truststore_passphrase -storetype JKS

The following example shows a command that is run to create a truststore with theze_sensor_truststore name and the Fa8asTek passphrase by using the ECC JRE.

ecc_install_path/jre/jre/bin/keytool -import -noprompt -alias key_alias -file <ECC install path>/certificates/key_alias.cert -keystore ze_sensor_truststore -storepass Fa8asTek -storetype JKS

2. Copy the truststore to the system where you configure the access list.3. In the Access Details window, select Data Collectors as the Component Type.4. Specify the access information of an ECC client with the Explorer role.5. Click SSL settings to import the ECC truststore file into TADDM.

a) In the Upload truststore Certificate field, specify the truststore file.b) In the Passphrase field, specify the passphrase.c) Specify the SSL Type as JKS.d) Leave the Key Store fields empty.

6. Click OK.

Configuring the discovery profileYou can use the following options to configure the zEnterprise sensor discovery.

Port sensor configurationYou must add the ECC port to the Portlist option of the Port sensor configuration and specify it in theenterpriseCCPortList option. The enterpriseCCPortList option is used to establish which port that islisted in the Portlist is the one that the ECC listens on. The sensor uses this option also to establish thelist of ports that are subject to additional actions, such as execution of the zEnterprise sensor. The samelist of ports must be specified in the portList option for the sensor to run.


ZEnterprise sensor configurationYou can use this configuration to extend timeout and retry counts to tune the connection to the ECC, or tochange any URL for queries if any alterations of those queries are made in the future ECC versions.

If you want to capture the entire zEnterprise landscape, you can set thestoreUnknownComputerSystems flag to true. This parameter forces the sensor to store a computersystem of an unknown type or the one without proper identification set.

Configuring the scopeScope must contain both the IP address of the host on which the ECC is deployed and its fully qualifieddomain name. This information is required for positive verification of the certificates that are used in theauthentication process.

Troubleshooting the sensorThis topic describes common problems that occur with the zEnterprise sensor and presents solutions forthose problems.

Error during sensor authenticationProblem

The sensor fails when it tries to authenticate with the ECC, and the sensor status information containsthe following error message:

CTJTD1541E Error during sensor authentication

Solution

• If the problem is related to Secure Socket Layer (SSL) configuration, the zEnterprise sensor logcontains the stack trace for a javax.net.ssl.SSLHandshakeException. Configure the SSLsettings in the access details again. It is possible that a truststore was not uploaded previously, orthat the truststore does not contain the right certificate for the ECC, or the truststore passphrase isincorrect.

• If the problem is related to the ECC logon, the ECC logs contain one of the following messages:CTGEZ0701E Authentication failed due to unknown user ID user_id.CTGEZ0702E Authentication failed due to invalid password for user ID user_id.CTGEZ0703E Authentication failed due to disabled user ID user_id.CTGEZ0704E Authentication failed due to too many invalid logon attempts by user ID user_id.CTGEZ0705E Authentication failed due expired password for user ID user_id.

The solution varies depending on the ECC log message found:

– Update the Data Collector access details by correcting the incorrect user name or password.– Update the client configuration on the ECC:

- Create a client- Enable the disabled client- Resume the client that has too many invalid logon attempts- Change the expired client password

• If the problem is not related to SSL configuration or the ECC logon, verify that the Data Collectoraccess details exist and that are not limited by scope. Create access details or change the scope onexisting access details.

Error during parsing the ECC dataProblem

The sensor fails when it tries to parse data that is returned from the ECC, and the sensor statusinformation contains the following error message:


CTJTD1542E The sensor failed when trying to parse data returned from the ECC

SolutionThe ECC encountered an error. Check the ECC log files to determine the solution.

Cannot connect to the ECC because the ECC API version is not supportedProblem

The version of the ECC API is not supported by this version of the zEnterprise sensor. The sensorstatus information contains the following error message:CTJTD1581E Could not connect to Enterprise Common Collector with hostname hostname because the Collector API version is not supported; supported api-major-version: supported_major_version; minimum supported api-minor-version: supported_minor_version; actual api-major-version: actual_major_version; actual api-minor-version: actual_minor_version

SolutionUpgrade the ECC or the zEnterprise sensor to a newer version.

The zEnterprise sensor does not runProblem

The sensor cannot connect to the ECC, and the Ping sensor status information indicates that it stored0 IP addresses in the database. Also, the Port sensor and the zEnterprise sensor do not run, or thePing sensor and the Port sensor both run but the zEnterprise sensor does not.

SolutionIf the Ping sensor indicates that it stored 0 IP addresses in the database, the ECC system cannot bereached. Verify that the host name and IP address that is provided for the ECC are correct. Also,ensure that there is no firewall between the sensor and the ECC.If the Ping sensor and Port sensor both run, the ECC does not listen on the expected port. Verify thatan ECC instance is installed and runs on the specified system, and that the portList andenterpriseCCPortList attributes of the Port sensor both contain the ECC port number. By default,the ECC listens on port 8443 but this port number can be changed during the ECC installation.

The zEnterprise sensor fails to completeProblem

The sensor experienced an unexpected unrecoverable error. The sensor status information containsthe following error message:CTJTD1544E Enterprise sensor failed to complete. Check log file for additional details

SolutionCheck the log file for more information.

The sensor skips unknown computer systemsProblem

The sensor cannot determine the type of the operating system that is running on a virtual server. Thesensor status information contains the following warning message:CTJTD1567E Skipping unknown computer system: computer

SolutionThis message occurs when a virtual server is inactive or when the Guest Platform ManagementProvider (GPMP) is not running on the virtual server. Activate the virtual server, install, and run theGPMP.Alternatively, you can change the storeUnknownComputerSystems flag to true to discover all suchvirtual servers. In such case, the systems are stored as ComputerSystem objects. You can accessthem from the Other Computer Systems section of the Data Management Portal.


The sensor skips unknown computer systems without proper identifiersProblem

The sensor cannot store a PowerVM® virtual server in TADDM. The sensor status information containsthe following warning message:CTJTD1568E Skipping computer system that has no proper identificators set: computer

SolutionThe zEnterprise HMC does not provide values for all of the attributes that are required to uniquelyidentify a PowerVM virtual server in the TADDM database. The only way to discover PowerVM virtualservers is to change the zEnterprise sensor configuration storeUnknownComputerSystems flag totrue. In such a case, all the PowerVM virtual servers and all virtual servers for which the sensorcannot determine the operating system type are discovered.

Network sensorsNetwork sensors discover network devices.

Overview of SNMP sensorsTADDM provides SNMP sensors for discovering SNMP network devices.

Calling sequence for SNMP sensorsThe calling sequence for SNMP sensors is dependent on which sensors are enabled in the discoveryprofile and on what data is discovered.

In Level 1 discovery profiles, use the SNMP Light sensor with the Stack Scan sensor to improve theaccuracy of the discovery. In Level 2 or Level 3 discovery profiles, use the SNMP MIB2 sensor, whichdiscovers additional data for building detailed Level 2 topologies.

Figure 1 on page 246 illustrates the calling sequence for the SNMP Light sensor and the SNMP MIB2sensor.

The ping sensor calls the port sensor.

If the SNMP Light sensor is enabled, the port sensor calls the SNMP Light sensor. If the port sensordiscovers WMI or SSH ports and if the session sensor is enabled, the port sensor launches the sessionsensor. If the port sensor does not discover WMI or SSH ports or if the session sensor cannot establish aconnection to the remote host, the port sensor calls the SNMP MIB2 sensor.

Figure 2 on page 246 illustrates the calling sequence for SNMP sensors, starting after the SNMP Lightsensor or the SNMP MIB2 sensor is called.

Depending on the data that the SNMP Light sensor or the SNMP MIB2 sensor discovers from the devices,the following sensors are called:

• If a Cisco device is discovered, the Cisco port sensor and the Cisco VLAN sensor are called.• If a Fibre Channel switch is discovered, the Fibre Channel switch sensor is called.• If no Fibre Channel switch is discovered, the Entity MIB sensor and the Bridge SNMP sensor are called.

However, these sensors must be enabled in the discovery profile.• If the discovered device matches a custom MIB computer system template, the Custom MIB2 computer

system sensor is called.


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

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

SNMP MIB walking and debugging SNMP sensorsYou can log SNMP get requests that are sent by the sensors.

To do so, add the following property to the collation.properties file:

com.collation.Discover.jvmargs=-Xmx2048M -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider-Dcom.collation.platform.snmp.SnmpPackedPDU.trace=true

You can then compare entries in the log file output with direct SNMP queries you run against the devicesusing 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.openssl.org/.


http://www.net-snmp.org/download.html

http://www.net-snmp.org/download.html

http://www.openssl.org/

http://www.openssl.org/

The following example shows identical queries, with the first using V3 authentication (although the keyshave been removed) and the second using community string authentication:

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "my authentication password" -x DES -X "my encryption key" 10.199.250.9 .1.3.6.1.2.1.4.20.1 snmpwalk -v 1 -c 5FFGkFaFNs 10.199.250.9 .1.3.6.1.2.1.4.20.1

Maintaining SNMP computer system templates and configuration filesYou can use the Computer Systems view to maintain a list of templates that can be used to discovernetwork devices.

You can partially define a device, link this definition to a template and then use the template to discovermore information about the device.

An OID is assigned to a device by the manufacturer and is unique to the make and model of the device.Similar devices of the same model have the same OID. You can typically determine the type of device youhave found by searching the Web. This value can also be obtained for the device by querying the SNMPv2-MIB tables for values under the sysObjectID 1.3.6.1.2.1.1.2.

The SNMP templates and their configuration files are loaded dynamically during each discovery. It is notnecessary to restart the TADDM server after modifying the SNMP templates and their configuration files.It is important to use the correct syntax and enter the correct values when editing templates andconfiguration files.

If your devices are not correctly classified after a discovery, review the SnmpMib2Sensor log or theDiscoveryManager log file.

For more information, see the Adding a computer system template for a network topic in the TADDM User'sGuide.

The following results show different OIDs discovered through SNMP scans of four Foundry devices. Inscanning a test environment, the OIDs outlined in Table 20 on page 247 were discovered. You canperform an Internet search to determine the type of devices. Alternatively, you can ask your network teamto identify the specific device types.

Table 20. Foundry OID mapping example

Foundry device OID Description

Foundry FESX448-PREM .1.3.6.1.4.1.1991.1.3.34.2.1.1.2 Router

Foundry FastIron SX .1.3.6.1.4.1.1991.1.3.36.6.2 Unknown (classified as a switchfor our testing)

Foundry BigIron RX .1.3.6.1.4.1.1991.1.3.40.1.2 Unknown (classified as a switchfor our testing)

Foundry NetIron MLX .1.3.6.1.4.1.1991.1.3.44.2.2 Unknown (classified as a routerfor our testing)

You can create templates to classify discovered Foundry devices.

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

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 usedduring or after discovery.)

7. Select MIB.8. In the Identifying Criteria field, select Any Criteria.9. For the first criterion, specify the following values:

Sys OID is .1.3.6.1.4.1.1991.1.3.34.2.1.1.1

Then click Add Criterion.10. For the second criterion, specify the following values:

Sys OID starts-with .1.3.6.1.4.1.1991.1.3.36

Then click Add Criterion.11. For the third criterion, specify the following values:


Then click Add Criterion.12. Click OK.

The new template is added to the end of the list.13. To add an action class file for the template, create a file named Foundry Switch.xml in the

$COLLATION_HOME/etc/templates/action directory.Add 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 FoundrySwitch template use the com.collation.platform.model.topology.sys.UnitaryComputerSystem modelclass, have the type attribute set to Bridge and the manufacturer attribute set to FoundryNetworks.

Note: The name of the action class file (without the .xml extension) must match the name of theSNMP computer system template.

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

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

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 usedduring or after discovery.)

7. Select MIB.8. In the Identifying Criteria field, select Any Criteria.9. For the first criterion, specify the following values:

Sys OID is .1.3.6.1.4.1.1991.1.3.34.2.1.1.2

Then click Add Criterion.10. For the second criterion, specify the following values:


Then click Add Criterion.11. Click OK.

The new template is added to the end of the list.12. To add an action class file for the template, create a file named Foundry Router.xml in the

$COLLATION_HOME/etc/templates/action directory.Add 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 FoundryRouter template use the com.collation.platform.model.topology.sys.UnitaryComputerSystem modelclass, have the type attribute set to Router and the manufacturer attribute set to FoundryNetworks.

Note: The name of the action class file (without the .xml extension) must match the name of theSNMP computer system template.

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

SNMP sensors propertiesYou can control the usage of SNMP sensors by modifying properties in the collation.properties file.

com.ibm.cdb.discover.snmp.login.timeout=5000This property specifies how long it takes before a login attempt fails.The default value is 5000 (milliseconds).

Alteon port sensorThe Alteon port sensor discovers Alteon switch port information, including ports that operate in autonegotiation mode and duplex mode.

The ports are stored in L2Interface with the auto negotiation (enabled or disabled) information. Theduplex mode (half duplex or full duplex) is also stored.


Sensor name that is used in the GUI and logsAlteonPortSensor

Object identifiers (OIDs) that are usedThe sensor uses the following OIDs:

• curCfgTable: .1.3.6.1.4.1.1872.2.1.2.3.2.1• portInfoTable: .1.3.6.1.4.1.1872.2.1.9.1.1.1


• net.L2Interface• sys.ComputerSystem



• For SNMP V1 and V2 discovery, complete the following steps:

1. Select Network Element (SNMP) as the Component Type.2. Specify the correct Community String.

• For SNMP V3 discovery, complete the following steps:

1. Select Network Element (SNMPV3) as the Component Type.2. Specify the correct user name, password, and authentication protocol, according to the SNMP V3

credential mapping information in the following table:

Map from this: To this:

Authentication type (MD5, for example) Authentication Protocol

MD5 Secret Key Password and Confirm Password

Private Authentication Description or Key Private Password

Restriction: To make an initial connection, the sensor requires SNMP version 1.

Alteon SNMP sensorThe Alteon SNMP sensor discovers Alteon load balancer devices.

The sensor discovers the following items:

• Real servers and real server groups. Real servers are partitioned into the respective real server groups.Additional information, such as the LoadBalancingAlgorithm, is also discovered and stored with the realserver group.

• Virtual ports, real ports, and virtual servers used to create and store virtual services.

Sensor name that is used in the GUI and logsAlteonSnmpSensor

Object identifiers (OIDs) that are usedThe sensor uses the following high-level OIDs to retrieve the attributes:


• .1.3.6.1.4.1.1872.2.1.5.5.1.1• .1.3.6.1.4.1.1872.2.1.5.5.1.2• .1.3.6.1.4.1.1872.2.1.5.5.1.4• .1.3.6.1.4.1.1872.2.1.5.2.1.1• .1.3.6.1.4.1.1872.2.1.5.2.1.2• .1.3.6.1.4.1.1872.2.1.5.2.1.3• .1.3.6.1.4.1.1872.2.1.5.2.1.10• .1.3.6.1.4.1.1872.2.1.5.10.1.1• .1.3.6.1.4.1.1872.2.1.5.10.1.2• .1.3.6.1.4.1.1872.2.1.5.10.1.3• .1.3.6.1.4.1.1872.2.1.5.10.1.7• .1.3.6.1.4.1.1872.2.1.5.8.1.1• .1.3.6.1.4.1.1872.2.1.5.8.1.2• .1.3.6.1.4.1.1872.2.1.5.8.1.3• .1.3.6.1.4.1.1872.2.1.5.8.1.4• .1.3.6.1.4.1.1872.2.1.5.8.1.5• .1.3.6.1.4.1.1872.2.1.5.8.1.6


• net.vip.RealServerGroup• net.vip.Vip• net.vip.VipFunction• net.vip.Virtualservice• sys.UnitaryComputerSystem• sys.Function net.vip.RealServer














Alteon VLAN sensorThe Alteon VLAN sensor discovers Alteon virtual LANs. This sensor uses the Alteon VLAN MembershipMIB to discover VLAN contents.

The SnmpMib2Sensor invokes the AlteonVlanSensor when VLANs are configured for Alteon devices.AlteonVlanSensor then invokes BridgeSnmpSensor2 for each VLAN discovered.

The sensor discovers the VLAN membership table, creates L2Interfaces, and attaches them to the VLANbridge.

Sensor name that is used in the GUI and logsAlteonVlanSensor


• .1.3.6.1.4.1.1872.2.1.4.2.1• .1.3.6.1.4.1.1872.2.1.2.3.2.1


• net.L2Interface• net.Vlan• net.VlanInterface• sys.UnitaryComputerSystem














BIG-IP port sensorThe BIG-IP port sensor discovers F5 BIG-IP port interfaces.

The SnmpMib2Sensor invokes the BigIPPortSensor. The BigIPPortSensor gathers ports from the MIB, forexample, the interface through which known ports can be addressed. This allows L2 topology views to bebuilt.

Sensor name that is used in the GUI and logsBigIPPortSensor

Object identifiers (OIDs) that are usedThe sensor follows the standards documented in RFC 1212 to retrieve ports from the MIB. Specifically,OID .1.3.6.1.4.1.3375.1.1.5.2.1 is queried to get the interface through which the port from the MIB canbe discovered.


• net.L2Interface• sys.UnitaryComputerSystem













BIG-IP SNMP sensorThe BIG-IP SNMP sensor discovers F5 BIG-IP load balancers.

The SnmpMib2Sensor invokes the BigIPSnmpSensor if the latter one matches one of the following OIDs:

• .1.3.6.1.4.1.3375• .1.3.6.1.4.1.2021.250.255

The BigIPSnmpSensor collects information about virtual IPs and real server groups.


Sensor name that is used in the GUI and logsBigIPSnmpSensor

Object identifiers (OIDs) that are usedThe sensor follows the standards that are documented in RFC 1212 to get the Real Server Database (RSD)and the Virtual Server Database (VSD) table entries.

The sensor uses the following OIDs:F5 BIG-IP version 4:

• Pool member table: 1.3.6.1.4.1.3375.1.1.8.2.1• Pool table: 1.3.6.1.4.1.3375.1.1.7.2.1• Virtual Server table: 1.3.6.1.4.1.3375.1.1.3.2.1

F5 BIG-IP version 9:

• 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• Virtual Address table: 1.3.6.1.4.1.3375.2.2.10.10.2• sysGeneralChassisSerialNum: 1.3.6.1.4.1.3375.2.1.3.3.3

F5 BIG-IP version 10:

• 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 Rule table: 1.3.6.1.4.1.3375.2.2.10.8.2• Virtual Address table: 1.3.6.1.4.1.3375.2.2.10.10.2• sysGeneralChassisSerialNum: 1.3.6.1.4.1.3375.2.1.3.3.3

Discovery of VIP IPv6

BigIPSnmpSensor is able to discover IPv6 VIP information of virtual and real server for Big IP devices.


• bigip.BigIPRealServer• bigip.BigIPRealServerGroup• bigip.BigIPVip• bigip.BigIPVipFunction• bigip.BigIPVirtualService• sys.UnitaryComputerSystem














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

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

Sensor name that is used in the GUI and logsBigIPVlanSensor

Object identifiers (OIDs) that are usedThe BigIPVlanSensor follows the standards documented in RFC 1212 to get the VLAN Interface.Specifically, OID .1.3.6.1.4.1.3375.1.1.10.2.1 is queried to get the VLAN interface through which theVLAN from the MIB can be discovered.

The BigIPVlanSensor runs the agent's discovery step and discovers Vlans and VlanInterfaces and throwsan AgentException if the discovery fails.


• bigip.BigIPVlan• net.L2Interface• net.VlanInterface






1. Select Network Element (SNMPV3) as the Component Type.


2. Specify the correct user name, password, and authentication protocol, according to the SNMP V3credential mapping information in the following table:






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

The SNMP MIB2 sensor invokes the Bridge SNMP sensor. The Bridge SNMP sensor gathers the MACaddress 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 ForwardingDatabase (fdb) table entries. The following OIDs are queried:

• .1.3.6.1.2.1.17.4.3.1.1• .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 thefollowing example. These OIDs are then queried to determine the interface through which the MAC devicecan be accessed.

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1 .1.3.6.1.2.1.17.4.3.1.1SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.42.208.0 = Hex-STRING: 00 12 F2 2A D0 00SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.50.0.0 = Hex-STRING: 00 12 F2 32 00 00SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.51.88.0 = Hex-STRING: 00 12 F2 33 58 00SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.218.128.177 = Hex-STRING: 00 12 F2 DA 80 B1SNMPv2-SMI::mib-2.17.4.3.1.1.0.208.4.45.228.10 = Hex-STRING: 00 D0 04 2D E4 0A

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1 .1.3.6.1.2.1.17.4.3.1.1.0.18.242.42.208.0SNMPv2-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.0SNMPv2-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 areattached to the switch. The SNMP MIB2 sensor provides generic information about the existence of thedevice interfaces, and the Bridge SNMP sensor provides detailed information about the MAC addressesthat are accessible through the device interfaces.

For example, Table 21 on page 256 shows the names of MAC devices that have been discovered by theBridge SNMP sensor. TADDM can determine the names because the computer system that owns that MACdevice has been discovered. If the name of the device is unknown, the MAC address is used.

Table 21. Level 2 bridge topology data

Name Computer System L2 Interfaces

ethernet 1/9 NC84CDRS1LDPC02

ethernet 1/10 00040DFDE53




Table 21. Level 2 bridge topology data (continued)

Name Computer System L2 Interfaces

ethernet 10/2 000CDBF90C19

The sensor also follows the standards that are documented in RFC 1286 to retrieve some of the port tableinformation. The following OIDs are queried:

• .1.3.6.1.2.1.17.1.4.1.1• .1.3.6.1.2.1.17.1.4.1.2

Sensor name that is used in the GUI and logsBridgeSnmpSensor

Object identifiers (OIDs) that are usedThe sensor follows the standards documented in RFC 1286 to get some of the MAC Forwarding Database(fdb) table entries. The following OIDs are queried:

• .1.3.6.1.2.1.17.4.3.1.1• .1.3.6.1.2.1.17.4.3.1.2

OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses. These OIDs are then queriedto retrieve the interface through which the MAC device can be accessed.


• net.L2Interface• net.Segment• sys.ComputerSystem
















com.ibm.cdb.discover.sensor.net.BridgeSnmpSensor.dot1dTpFdbStatusThis property specifies the values of the dot1dTpFdbStatus object.By default, TADDM supports values 1, 3, and 5.If you use network switches that support other values than the default ones, add this property to thecollation.property file with the specified values.

com.collation.discover.agent.net.BridgeSnmpAgent.filterCiscoTrunkPortThis property specifies whether the sensor ignores the discovery of MAC addresses on the trunk portsof Cisco devices.In TADDM 7.3.0.2 and earlier, the default value is false, which means that MAC addresses arediscovered. If you want to disable it, add this property to the collation.properties file and set itto true.

Important: If you set this property to true, you must also enable the CDP Protocol for the discoveryswitches, and you must enable the CdpSensor in the discovery profile.

In TADDM 7.3.0.3, and later, the default value is true. To enable the discovery of MACaddresses on trunk ports, add this property to the collation.properties file and set it to false.

com.collation.discover.agent.net.BridgeSnmpAgent.filterLLDPTrunkPortThis property specifies whether the sensor ignores the discovery of MAC addresses on the FDB switchtrunk ports.In TADDM 7.3.0.2, the default value is false, which means that MAC addresses are discovered. If youwant to disable it, add this property to the collation.properties file and set it to true.

Important: If you set this property to true, you must also enable the LLDP Protocol for the discoveryswitches, and you must enable the LldpSensor in the discovery profile.


com.collation.discover.agent.net.BridgeSnmpAgent.filterExtremeTrunkPortThis property specifies whether the sensor ignores the discovery of MAC addresses on the trunk portsof Extreme devices.In TADDM 7.3.0.2, the default value is false, which means that MAC addresses are discovered. If youwant to disable it, add this property to the collation.properties file and set it to true.

Important: If you set this property to true, you must also enable the EDP Protocol for the discoveryswitches, and you must enable the ExtremeVlanSensor in the discovery profile.


Bridge SNMP 2 sensorThe Bridge SNMP 2 sensor expands and updates the port data that is discovered by the SNMP MIB2sensor for all virtual local area networks (VLANs).

The Bridge SNMP 2 sensor is invoked when VLANs are configured for the device. The Cisco VLAN sensorinvokes the Bridge SNMP 2 sensor for each VLAN that is discovered. The data that is discovered is thesame as for the Bridge SNMP sensor, but it is discovered for all VLANs.

Sensor name that is used in the GUI and logsBridgeSnmpSensor2


Object identifiers (OIDs) that are usedThe sensor follows the standards documented in RFC 1286 to get some of the MAC Forwarding Database(fdb) table entries. The following OIDs are queried:

• .1.3.6.1.2.1.17.4.3.1.1• .1.3.6.1.2.1.17.4.3.1.2.

OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses. These OIDs are then queriedto retrieve the interface through which the MAC device can be accessed.


• net.L2Interface• net.Segment• sys.ComputerSystem















com.ibm.cdb.discover.sensor.net.BridgeSnmpSensor.dot1dTpFdbStatusThis property specifies the values of the dot1dTpFdbStatus object.By default, TADDM supports values 1, 3, and 5.If you use network switches that support other values than the default ones, add this property to thecollation.property file with the specified values.

com.collation.discover.agent.net.BridgeSnmpAgent.filterCiscoTrunkPortThis property specifies whether the sensor ignores the discovery of MAC addresses on the trunk portsof Cisco devices.


In TADDM 7.3.0.2 and earlier, the default value is false, which means that MAC addresses arediscovered. If you want to disable it, add this property to the collation.properties file and set itto true.

Important: If you set this property to true, you must also enable the CDP Protocol for the discoveryswitches, and you must enable the CdpSensor in the discovery profile.


com.collation.discover.agent.net.BridgeSnmpAgent.filterLLDPTrunkPortThis property specifies whether the sensor ignores the discovery of MAC addresses on the FDB switchtrunk ports.In TADDM 7.3.0.2, the default value is false, which means that MAC addresses are discovered. If youwant to disable it, add this property to the collation.properties file and set it to true.

Important: If you set this property to true, you must also enable the LLDP Protocol for the discoveryswitches, and you must enable the LldpSensor in the discovery profile.


com.collation.discover.agent.net.BridgeSnmpAgent.filterExtremeTrunkPortThis property specifies whether the sensor ignores the discovery of MAC addresses on the trunk portsof Extreme devices.In TADDM 7.3.0.2, the default value is false, which means that MAC addresses are discovered. If youwant to disable it, add this property to the collation.properties file and set it to true.

Important: If you set this property to true, you must also enable the EDP Protocol for the discoveryswitches, and you must enable the ExtremeVlanSensor in the discovery profile.


com.collation.discover.agent.BridgeSnmpAgent.MACAddressPrefixSkipListThis property skips MAC addresses from a network device. Use this property to filter desktops and anyother physical devices, when TADDM scans network devices.The value of this property is a list of comma-separated MAC address prefixes that are matched withthe entries that the sensor finds in the Forwarding Database table. When a MAC address and an entryfrom the table match, the device is ignored.

Check Point sensorThe Check Point sensor discovers Check Point FireWall-1 running on non-Windows platforms, such asSolaris or Check Point IPSO.

Sensor name that is used in the GUI and logsCheckpointSensor

PrerequisitesYou must have the following access:

• SSH access that can run lsof• Read permission to the $CPMDIR/conf/objects.C directory on the system where the Check Point

FireWall-1 is running• Execute permission for the $CPMDIR/bin/fw command• Read permission to the $CPMDIR/conf/*.W files, which contain the editable versions of the rule sets

The CPMDIR environment variable must be set for the TADDM user.



collation.properties file entriesThe following properties can require elevated privilege:

• com.collation.discover.agent.command.cat.SunOS=cat• com.collation.discover.agent.command.cat.SunOS.1.2.3.4=sudo cat

Troubleshooting the sensorThis topic describes common problems that occur with the Check Point sensor and presents solutions forthose problems.

Unable to retrieve information from the Check Point server host machineProblem

The Check Point sensor fails during discovery.Solution

Verify that you have the following permissions:

• Read permission to the $CPMDIR/conf/objects.C directory on the system where the Check PointFireWall-1 is running

• Execute permission for the $CPMDIR/bin/fw command• Read permission to the $CPMDIR/conf/*.W files, which contain the editable versions of the rule

sets

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

Sensor name that is used in the GUI and logsCheckpointSnmpSensor

PrerequisitesThe system object ID (sysObjectID) must return one of the following OIDs:

• OID = .1.3.6.1.4.1.1919.• OID = .1.3.6.1.4.1.2620.• OID.startsWith(.1.3.6.1.4.1.42.2.1.1.)

LimitationsThe sensor collects the module, filter name, filter installation date, product name, major name, and minorname information.




1. Select Network Element (SNMP) as the Component Type.


2. Specify the correct Community String.• For SNMP V3 discovery, complete the following steps:








Cisco Adaptive Security Appliance sensorThe Cisco Adaptive Security Appliance (ASA) sensor discovers ASA devices that are used as IP firewalland network address translation appliances.

The Cisco ASA sensor gathers data about ASA devices. In addition, the sensor discovers the followinginformation:

• All real servers and virtual services running. Real servers are grouped into the real servers group.• The virtualIp, realIp, virtualPort, and realPort. The sensor also derives virtual IPs using the virtualIp,

realIp, virtualPort, and realPort. Virtual IPs are stored in the Vip table.

Sensor name that is used in the GUI and logs• ASASensor• CiscoApplianceVersionSensor

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


• cisco.CiscoPixComputerSystem• core.LogicalContent• net.L2Interface• sys.OperatingSystem• vip.RealServer• vip.RealServerGroup• vip.Vip• vip.VipFunction• vip.VirtualService





1. Select Cisco Device as the Component Type.2. Specify the access information (user name, password, and enable password) that TADDM must use for

authentication to the target ASA device.

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

The sensor uses the following entries in the collation.properties file:com.collation.asa.pager.command=terminal pager 0

Add this property and value if the user specified in the access list does not have access to theconfigure terminal command.

The terminal pager 0 value instructs the pager command to force the ASA device to returnresponses in one batch.

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

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

Cisco Discovery Protocol sensorThe Cisco Discovery Protocol sensor uses the Cisco Discovery Protocol MIB to discover Layer 2 segmentson the network.

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

Sensor name that is used in the GUI and logsCdpSensor


• Global Device Id : 1.3.6.1.4.1.9.9.23.1.3.4.0• Cache Device Id : .1.3.6.1.4.1.9.9.23.1.2.1.1.6• Cache Device Port : .1.3.6.1.4.1.9.9.23.1.2.1.1.7


• net.L2Interface• net.Segment


• sys.ComputerSystem












• For TADDM to run a complete discovery, SNMP and Telnet must be enabled. You must configure Telnetaccess with a user name and password, and you must enable the password.

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

After TADDM completes the discovery, the sensor name appears in the GUI, but theConfig files tab does not appear as expectedProblem

Telnet access is not configured correctly.Solution

Configure Telnet access with a user name and password, and make sure that the password is enabled.

Cisco IOS sensorThe Cisco Internetwork Operating System (Cisco IOS) sensor discovers Cisco network equipment using anSSH1, SSH2, or Telnet protocol.

The Cisco IOS sensor supports two-stage authentication:

• Create the appropriate session client for SSH1, SSH2, or Telnet protocol.• Log on to the host.

Sensor name that is used in the GUI and logsCiscoIOSSensor


• agent.CiscoIOSAgentConfiguration• core.LogicalContent





The following sensor attributes can be modified from the discovery profile:useSshFirst

The default value for this attribute is false. The protocols are probed in the order: Telnet protocol,SSH2, and SSH1. If the value is true: the protocols are probed in the order: SSH2, SSH1, and Telnetprotocol.

commandsThe default values for this attribute are show running-config;show startup-config, if novalue is entered. The output for each command is saved as a configuration file. To add additionalcommands, type the default commands show running-config;show startup-config and addadditional commands to the list. Separate each command with a semicolon. Alternatively, type thecommands you want to run.



1. Select CiscoDeviceAuth as the Component Type.2. Specify the access information (user name, password, and enable password) that TADDM must use for

authentication to the target computer system. Leave the enable password blank if not required.3. If your Cisco IOS sensor is using a Telnet protocol and does not prompt for a user name, type default

in the user name field.

Cisco port sensorThe Cisco port sensor discovers Cisco switch port information.

The CiscoPortSensor discovers the interface index and duplex state for the port. It also determines theauto negotiation status.

Sensor name that is used in the GUI and logsCiscoPortSensor

Object identifiers (OIDs) that are usedThe sensor uses OID .1.3.6.1.4.1.9.9.87.1.4.1.1 for 2900 series Cisco devices. OtherwiseOID .1.3.6.1.4.1.9.5.1.4.1.1 is used.
















Cisco UCS SNMP sensorThe Cisco UCS SNMP sensor discovers and collects configuration information about Cisco UCS device. Ituses SNMP (Simple Network Management Protocol) to discover and query Cisco UCS infrastructurecomponents.

Sensor name that is used in the GUI and logsCiscoUCSSensor

Limitations• The sensor does not discover certain types of data. See the following list for details.

Note: In TADDM 7.3.0.3, and later, these limitations do not apply.

– Fabric Interconnect information is not available in the UI. You can view it only through the CLIinterface.

– The relationship between Fabric Interconnect and Chassis is not created.– IO Modules are not discovered.– Blade CPU model object and Memory Information attribute are not discovered.

• Sensor does not discover Cisco UCS Cluster and Cisco UCS Pool objects.

Model objects with associated attributesThe Cisco UCS SNMP sensor creates model objects with associated attributes. The attributes indicate thetype of information that the sensor collects about Cisco UCS devices.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.CiscoUCSBladeServer

• AdminState• DistinguishedName• Model• Presence• RelativePosition


• SerialNumber• SystemBoardUUID

CiscoUCSChassis

• DistinguishedName• HWRevision• Model• OperationalState• SerialNumber

CiscoUCSFabricInterconnect

• DistinguishedName• HWRevision• Model• OperationalState• SerialNumber• Thermal

CiscoUCSServiceProfile

• AssignedState• AssocState• DistinguishedName• Label• ProfileType• OperationalState• OriginNode

enums.PhysTypeEnumenums.SlotStateEnumnet.Fqdnphys.physconn.PhysicalConnectorphys.physconn.Slot

• HWRevision• Name• Parent• PhysicalFrame• RelativePosition• SlotState• Type

phys.physpkg.Board

• DistinguishedName• Model• ModuleSide• Name• OperationalState• PhysicalPackage


• Presence• RelativePosition• RunningVersion• SerialNumber• StartupVersion• Thermal• Type

phys.physpkg.Fan

• Name• HWRevision• RelativePosition• SerialNumber

phys.physpkg.PhysicalFramephys.physpkg.PowerSupply

• Name• HWRevision• RelativePosition• SerialNumber

sys.ComputerSystem




• For SNMP V1 and V2 discovery, enter the correct Community String into the access list.

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

• For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into theaccess list, according to the SNMP V3 credential mapping information in the following table.

Table 22. SNMP V3 credential mapping.


Authentication type (for example MD5) Authentication Protocol



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


You can configure the discovery profile of CiscoUCSSensor in the Discovery Management Console bysetting the following attributes:


snmpPortThe port number that is used for SNMP communication. The default value is 161.

snmpTimeoutThe timeout that is used for a single SNMP query. The default value is 20000 (seconds).

localeThe locale that is used for SNMP queries.

characterEncodingThe character encoding that is used for SNMP queries.

When the CiscoUCSSensor is enabled, you must also enable the SnmpLightSensor or SnmpMIB2Sensorfor the CiscoUCSSensor to function correctly.

For more information about discovery profiles, see the Creating discovery profiles topic in the TADDMUser's Guide.

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

An SNMP timeout error occursProblem

The sensor generates an SNMP timeout error during discovery.Solution

Increase the snmpTimeout parameter for the CiscoUCSSensor by using the Discovery ManagementConsole.

Cisco VLAN sensorThe Cisco VLAN sensor uses the Cisco VLAN Membership MIB to discover VLAN contents.

The SnmpMib2Sensor invokes CiscoVlanSensor when VLANs are configured for Cisco devices. TheCiscoVlanSensor then invokes BridgeSnmpSensor2 for each VLAN using the ethernet protocol. The sensordiscovers the VLAN membership table, creates L2Interfaces, and attaches them to the VLAN bridge.

Note: Default VLANs, token ring, etc, will not spawn a BridgeSnmpSensor2.

Sensor name that is used in the GUI and logsCiscoVlanSensor

Object identifiers (OIDs) that are usedThe sensor follows the standards documented in RFC 1286 to get the VLAN interface. The high level OIDsqueried are:

• OID .1.3.6.1.4.1.9.9.68.1.2.2.1.2 to get the VLAN membership table• OID .1.3.6.1.4.1.9.9.46.1.2.1.1 to get the management domain table• OID .1.3.6.1.4.1.9.9.46.1.3.1.1 to get the vtp VLAN table• OID .1.3.6.1.4.1.9.9.46.1.6.1.1 to get the VLAN trunk port information.


• net.L2Interface• net.Vlan


• net.VlanInterface• sys.UnitaryComputerSystem













CiscoWorks sensorThe CiscoWorks sensor collects data from CiscoWorks servers.

The sensor works by invoking the RME servlet.

Sensor name that is used in the GUI and logsCiscoWorksSensor, CiscoWorks405FileSensor, CiscoWorks405FileUDS, CiscoWorks405UDS,CiscoWorksFileSensor, CiscoWorksFileUDS, and CiscoWorksUDS

LimitationsCiscoWorks sensor does not discover CiscoWorks LMS or Cisco Prime LMS, when the secure (HTTPS)mode is enabled for CiscoWorks server or Cisco Prime server.

Commands that the sensor runsThe sensor sends the HTTP POST request method to the following URL:

http://<Cisco Works IP>:1741/rme/cwcli

The payload contains the cwcli export inventory command.

Model objects with associated attributesThe CiscoWorks sensor creates model objects with associated attributes. The attributes indicate the typeof information that the sensor collects about configuration items from CiscoWorks servers.



net.IpAdress

• DotNotation

net.IpInterface

• IpAddress• L2Interface

net.L2Interface

• Description• Encapsulation• HwAddress• Name

net.Router

• Forwarding• Name

sys.OperatingSystem

• Description• Name• OSName• OSVersion

sys.UnitaryComputerSystem

• Functions• Manufacturer• Model• Name• OSRunning• SerialNumber• Type



1. Use CiscoWorks as the Component Type.2. Specify the following required information:


Troubleshooting the sensorFind out what common problems might occur with the CiscoWorks sensor and how to solve them.

Invalid XML formatProblem

When trying to create model objects, the following error occurs:

CTJTD0652E The following transformation did not complete successfully: CTJTP2203E The server cannot create model objects: [PLATFORM.XML.E.1]


The application is unable to parse the xml input.. .

SolutionThe cause of this problem is the opening quotation mark (") found in the CiscoWorks configuration.This character is unsupported. To solve the problem, remove the opening quotation mark from theconfiguration.

Entity MIB sensorThe Entity MIB sensor can discover only known devices. It follows the standards that are documented inRFC 2737 to retrieve some of the physical configuration information for the device.

The Entity MIB sensor gathers the data that is shown in the PhysicalPackage tab of the Details pane. Thisdata is used to store information about physical parts of the device such as slot, fan, physical frame,sensors, physical connectors, chassis, rack, and power supply.

The sensor queries the following OIDs:

.1.3.6.1.2.1.47.1.1.1.1.2, .1.3.6.1.2.1.47.1.1.1.1.3, .1.3.6.1.2.1.47.1.1.1.1.4,

.1.3.6.1.2.1.47.1.1.1.1.5, .1.3.6.1.2.1.47.1.1.1.1.6, .1.3.6.1.2.1.47.1.1.1.1.7,

.1.3.6.1.2.1.47.1.1.1.1.8, .1.3.6.1.2.1.47.1.1.1.1.9, .1.3.6.1.2.1.47.1.1.1.1.10,

.1.3.6.1.2.1.47.1.1.1.1.11, .1.3.6.1.2.1.47.1.1.1.1.12, .1.3.6.1.2.1.47.1.1.1.1.13.

The sensor also gathers .1.3.6.1.2.1.55.1.1.0., which contains IPv6 information according to RFC2466. OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses. These OIDsare then queried to determine the interface through which the MAC device can be accessed.

If the SNMP MIB2 sensor also runs, additional information is gathered and shown in the Router Details,Bridge Details, IP, and Ports tabs.

Sensor name that is used in the GUI and logsEntityMIBSensor


• .1.3.6.1.2.1.47.1.1.1.1.2• .1.3.6.1.2.1.47.1.1.1.1.3• .1.3.6.1.2.1.47.1.1.1.1.4• .1.3.6.1.2.1.47.1.1.1.1.5• .1.3.6.1.2.1.47.1.1.1.1.6• .1.3.6.1.2.1.47.1.1.1.1.7• .1.3.6.1.2.1.47.1.1.1.1.8• .1.3.6.1.2.1.47.1.1.1.1.9• .1.3.6.1.2.1.47.1.1.1.1.10• .1.3.6.1.2.1.47.1.1.1.1.11• .1.3.6.1.2.1.47.1.1.1.1.12• .1.3.6.1.2.1.47.1.1.1.1.13

The sensor queries OID .1.3.6.1.2.1.55.1.1.0. which contains the IPV6 information per RFC 2466. Thesensor also queries OID .3.6.1.2.1.17.4.3.1.1. which returns a list containing OIDs for known MACaddresses. These OIDs are then queried to get the interface through which the MAC device can beaccessed.



• phys.physconn.Slot• physconn.PhysicalConnector• physpkg.Chassis• physpkg.Fan• physpkg.PhysicalFrame• physpkg.PhysicalPackage• physpkg.otherPhysicalPackage• physpkg.PowerSupply• physpkg.Sensor• sys.ComputerSystem













Extreme VLAN sensorThe Extreme VLAN sensor extracts VLAN information from Extreme Networks switches.

The SnmpMib2Sensor invokes the ExtremeVlanSensor when VLANs are configured for the device.

Sensor name that is used in the GUI and logsExtremeVlanSensor


• OID .1.3.6.1.4.1.1916.1.2.1.2.1 is used to query the extremeVlanInterface Information.• OID .1.3.6.1.4.1.1916.1.2.3.1.1 is used to query the Encapsulation (Trunk) Interface information.• OID .1.3.6.1.2.1.31.1.2.1 is used to query the Interface Stack information.
















IBM BladeCenter SNMP sensorThe IBM BladeCenter SNMP sensor discovers and collects configuration information about IBMBladeCenter chassis. In TADDM 7.3.0.3, and later, it also discovers and collects configuration informationabout IBM PureFlex System chassis.

The sensor uses SNMP (Simple Network Management Protocol) to discover and query BladeCenterinfrastructure components. The Management Module (MM) and the Advanced Management Module(AMM) are the central points of management for the IBM BladeCenter chassis.

The Chassis Management Module (CMM) is the central point of management for the PureFlex®

chassis.

Sensor name that is used in the GUI and logsBladeCenterSnmpSensor

LimitationsThe following limitations apply to discovery of both IBM BladeCenter chassis and IBM PureFlex Systemchassis:

• The sensor cannot discover chassis if the any of the Management Modules is not responsive.• The sensor cannot discover BladeCenters that have two configured network interfaces (eth0 and eth1).• You cannot start the first BladeCenter discovery against an empty database. Computer system sensors

that discover operating systems that run on blades (such as Linux and Windows) must be run first. Thislimitation applies only to the first BladeCenter discovery.

• The sensor might not obtain sufficient Vital Product Data (VPD) against Redundant ManagementModules to create certain model objects. Instances of the ComputerSystem and


BladeCenterManagementModule classes that represent Redundant Management Modules, forexample, might not be created. In this case, instances of the Board class represent the module.

• After you discover one or more BladeCenters by using the BladeCenter sensor, the componentsBladeCenter and BladeCenter Management Module are not present in the list of component typesavailable for use with custom queries. Therefore, you cannot run a custom query for these types ofcomponents. This issue applies only to the TADDM Data Management Portal and not to the DiscoveryManagement Console.

• The BladeCenter does not have L2 interfaces but has Management Modules that have L2 interfaces. Toview the L2 interfaces of the Management Modules contained in the BladeCenter, complete thefollowing steps:

1. In the Details pane, click the Chassis tab to open the Chassis notebook.2. Click the MMs tab to open the Management Module notebook.3. In the Computer System column, click BladeCenter Management Module.4. Click the IP tab to view the L2 interface details.

The following limitations apply to discovery of IBM PureFlex System chassis only:

• When IBM PureFlex System chassis contains IBM Storwize® v7000 storage, the sensor discoversplaceholders for the storage enclosures. To fully discover information about this storage, you must alsorun the SVC Storage sensor. The data that is discovered by the SVC Storage sensor is reconciled withthese placeholders.

• When you discover IBM PureFlex System chassis, the sys.blade.Alert model object is not created.


• core.LogicalContent• enums.AlertLevelEnum• enums.PhysTypeEnum• enums.SlotStateEnum• IpAddress net• L2Interface• net.BindAddress• net.Fqdn net• phys.physconn.PhysicalConnector• phys.physconn.Slot• phys.physpkg.Board• phys.physpkg.Chassis• phys.physpkg.Fan• 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



You can configure the BladeCenterSnmpSensor using the Discovery Management Console by setting thefollowing attributes:

snmpPortThe port number used for SNMP communication. The default value is 161.

snmpTimeoutThe timeout used for a single SNMP query. The default value is 20000.

localeThe locale used for SNMP queries.

characterEncodingThe character encoding used for SNMP queries.

scanL2InterfacesGet L2 interfaces for the chassis, when enabled.

For more information, see the Creating discovery profiles topic in the TADDM User's Guide.

When the BladeCenterSnmpSensor is enabled, you must also enable the SnmpLightSensor orSnmpMIB2Sensor for the BladeCenterSnmpSensor to function correctly.














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

An SNMP time out error occursProblem

The sensor generates an SNMP time out error during discovery.Solution

Increase the snmpTimeout parameter for the BladeCenterSnmpSensor using the DiscoveryManagement Console.

LAN Manager SNMP sensorThe LAN Manager SNMP sensor discovers LAN Manager and retrieves information contained in LANManager SNMP MIBs.

Sensor name that is used in the GUI and logsLanManagerSnmpSensor


• .1.3.6.1.4.1.77.1.1.1.0• .1.3.6.1.4.1.77.1.1.2.0• .1.3.6.1.4.1.77.1.2.3.1.1• .1.3.6.1.4.1.77.1.2.3.1.2• .1.3.6.1.4.1.77.1.2.3.1.3• .1.3.6.1.4.1.77.1.2.3.1.4• .1.3.6.1.4.1.77.1.2.3.1.5


• sys.windows.WindowsComputerSystem• sys.windows.WindowsOperatingSystem• sys.windows.WindowsService














LDAP sensorThe LDAP sensor discovers LDAP servers.

The LDAP sensor always discovers one LDAP instance per host.

Sensor name that is used in the GUI and logsLdapSensor

Model objects createdThe sensor creates the model object sys.LDAPSAP.

To discover all attributes, the user specified in the access list must have an access to the cn=monitorsubtree on the LDAP server and the cn=monitor subtree must exist.

Configuring the sensorBefore you run a discovery, you must configure the LDAP sensor.

Setting sensor configuration parametersYou can configure the behavior of the LDAP sensor by setting the configuration parameters.

To modify the sensor configuration, you can configure the following parameters:tryInsecureConnection

Specifies whether to use insecure connection. The default value of this property is true.If this parameter is set to true, in case when the sensor connects by using the LDAPS or StartTLSprotocols and fails, the sensor tries to connect to LDAP by using a plain protocol. If this property is setto false, the sensor tries to connect by using the LDAPS or StartTLS protocols only.To learn where to configure LDAP ports, see “Configuring the collation.properties file entries” on page279.

bypassHostVerificationSpecifies whether to bypass the host verification procedure. The default value of this property istrue.If this property is set to true and LDAP is discovered by using the StartTLS protocol, the TLSnegotiation step bypasses the host verification procedure. The sensor accepts the certificates that aresigned for a different host name or IP address of the target server that was provided in the scope usedfor the discovery. If this property is set to false, the sensor tries to run the TLS negotiation step byusing IP address of the target host.

Configuring the access listDepending on your configuration, you must provide required access details.


1. Use LDAP Service as the Component Type.2. Specify the access information (a user name and password) that TADDM uses to authenticate with the

LDAP server.


3. Optionally, in case of LDAP secured by the LDAPS or StartTLS protocols, provide the SSL settings, thatis truststore certificate and its password.

Using SSLThe LDAP sensor uses the first access entry to connect to the LDAP service. To enforce using SSL,either put the SSL access entry for LDAP before entries with plain credentials or set thetryInsecureConnection property to false.

The installation could fail if SSL is enforced. By default http is used (http is hardcoded inDownloadFilesDeomPrimaryServerAction).

Trust store files limitationDue to a limitation in Java, TADDM can handle only one truststore file for a single discovery of LDAPservice. The certificates that are stored in the truststore file are loaded when the connection withLDAP service is established. Only those certificates can be used by TADDM during the entire discovery,so if certificates from several truststore files are required, do not attach them separately into theaccess list. You must export the original truststore files to a single file. When all necessary entries foreach LDAP server are in the TADDM access list, the first one must have the exported truststore fileattached. There is always one entry for each different login and password combination for thediscovered LDAP servers.

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

The LDAP sensor uses the following sensor settings:com.collation.ldapsensor.ports.ldaps=636

Specifies a comma separated list of ports, on which LDAP is running by using the LDAPS protocol.com.collation.ldapsensor.ports.starttls=389

Specifies a comma separated list of ports, on which LDAP is running by using the StartTLS protocol.

Note:

• If the tryInsecureConnection property is set to true in the sensor configuration, sensor tries toconnect to the preceding ports also by using a plain LDAP protocol, starting with StartTLS ports.

• The values of both properties are also used by PortSensor to determine which ports are open.• Both values can be also set in the Platform Properties tab in profiles.• These properties are scoped properties and can be set for a specific IP of target machines, for examplecom.collation.ldapsensor.ports.ldaps.192.168.5.4=755,234,524.

Troubleshooting the sensorThis topic describes common problems that occur with the LDAP sensor and presents solutions for thoseproblems.

Error occurs during a discoveryProblem

The sensor discovery finishes with the following error message:

CTJTD0421E The LDAP server contains the following unexpected attributes: javax.naming.AuthenticationNotSupportedException: [LDAP: error code 13 - confidentiality required]

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


Sensor cannot display all attribute informationProblem

The following attribute information is not displayed after running a discovery: LDAP Version,Threads, and Total Connections.

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

Duplicates of LDAPService instancesProblem

When the LDAP server listening port changes between two discoveries, duplicates of LDAPServiceinstances might occur after each discovery.

SolutionAdd target server's session credentials to the access list. Check whether the ComputerSystemsensors, such as LinuxComputerSystemSensor, are enabled in the discovery profile. AfterLDAPServiceAgent run, LDAPService instances are merged, if discovered on the same host.

Link Layer Discovery Protocol sensorThe Link Layer Discovery Protocol sensor uses the LLDP MIB to discover Layer 2 segments on thenetwork. The LldpSensor discovers lldpLocalSystemData , lldpLocPortTable and lldpRemTable informationand builds the local interface for the peer devices. This interface is used to build the segment.


Sensor name that is used in the GUI and logsLldpSensor


• lldpLocChassisIdSubtype : .1.0.8802.1.1.2.1.3.1• lldpLocChassisId : .1.0.8802.1.1.2.1.3.2• lldpLocSysName : .1.0.8802.1.1.2.1.3.3• lldpLocPortNum: .1.0.8802.1.1.2.1.3.7.1.1• lldpLocPortIdSubtype: .1.0.8802.1.1.2.1.3.7.1.2• lldpLocPortId: .1.0.8802.1.1.2.1.3.7.1.3• lldpLocPortDesc: .1.0.8802.1.1.2.1.3.7.1.4• lldpRemTableIdx: .1.0.8802.1.1.2.1.4.1.1.1• lldpRemChassisIdSubtype: .1.0.8802.1.1.2.1.4.1.1.4• lldpRemChassisId: .1.0.8802.1.1.2.1.4.1.1.5• lldpRemPortIdSubtype: .1.0.8802.1.1.2.1.4.1.1.6• lldpRemPortId: .1.0.8802.1.1.2.1.4.1.1.7• lldpRemPortDesc: .1.0.8802.1.1.2.1.4.1.1.8


• net.L2Interface• net.Segment



NetScreen SNMP sensorThe NetScreen SNMP sensor discovers the NAT configuration from Juniper Networks NetScreen devicesand retrieves service values such as ServiceIndex, serviceName, and ServiceTransProto from NetScreenand looks up the virtualservice.

The NetScreenSNMPSensor uses the Netscreen SNMP MIBs.

Sensor name that is used in the GUI and logsNetscreenSnmpSensor


• .1.3.6.1.4.1.3224.11.1.1.1• .1.3.6.1.4.1.3224.11.1.1.2• .1.3.6.1.4.1.3224.11.1.1.3• .1.3.6.1.4.1.3224.11.1.1.4• .1.3.6.1.4.1.3224.11.1.1.5• .1.3.6.1.4.1.3224.11.1.1.6• .1.3.6.1.4.1.3224.13.1.1.1• .1.3.6.1.4.1.3224.13.1.1.2• .1.3.6.1.4.1.3224.13.1.1.4• .1.3.6.1.4.1.3224.13.1.1.5• .1.3.6.1.4.1.3224.13.1.1.6• .1.3.6.1.4.1.3224.13.1.1.7• .1.3.6.1.4.1.3224.13.1.1.8• .1.3.6.1.4.1.3224.11.3.1.1.1• .1.3.6.1.4.1.3224.11.3.1.1.2• .1.3.6.1.4.1.3224.11.3.1.1.3• .1.3.6.1.4.1.3224.11.3.1.1.4• .1.3.6.1.4.1.3224.11.3.1.1.5• .1.3.6.1.4.1.3224.11.3.1.1.6• .1.3.6.1.4.1.3224.11.3.2.1.1• .1.3.6.1.4.1.3224.11.3.2.1.2• .1.3.6.1.4.1.3224.11.3.2.1.3• .1.3.6.1.4.1.3224.11.3.2.1.5• .1.3.6.1.4.1.3224.11.3.2.1.6


• net.vip.RealServer• net.vip.RealServerGroup• net.vip.Vip• net.vip.VipFunction


• net.vip.VirtualService• sys.ComputerSystem













Nokia SNMP sensorThe Nokia SNMP sensor discovers information contained in Nokia SNMP MIBs.

The NokiaSNMPSensor discovers Access Control List (ACL) configurations (ACL rules) and mappedinterfaces for Nokia SNMP devices based on the FQDN, signature, and Object_ID.

Sensor name that is used in the GUI and logsNokiaSnmpSensor


• .1.3.6.1.4.1.94.1.16.4.1.1.1.1• .1.3.6.1.4.1.94.1.16.4.1.1.1.2• .1.3.6.1.4.1.94.1.16.4.1.1.1.3• .1.3.6.1.4.1.94.1.16.4.1.1.1.4• .1.3.6.1.4.1.94.1.16.4.1.1.1.5• .1.3.6.1.4.1.94.1.16.4.2.1.1.1• .1.3.6.1.4.1.94.1.16.4.2.1.1.2• .1.3.6.1.4.1.94.1.16.4.2.1.1.3• .1.3.6.1.4.1.94.1.16.4.2.1.1.4• .1.3.6.1.4.1.94.1.16.4.2.1.1.5• .1.3.6.1.4.1.94.1.16.4.2.1.1.6• .1.3.6.1.4.1.94.1.16.4.2.1.1.7• .1.3.6.1.4.1.94.1.16.4.2.1.1.8


• .1.3.6.1.4.1.94.1.16.4.2.1.1.9• .1.3.6.1.4.1.94.1.16.4.2.1.1.10• .1.3.6.1.4.1.94.1.16.4.2.1.1.11• .1.3.6.1.4.1.94.1.16.4.2.1.1.12• .1.3.6.1.4.1.94.1.16.4.2.1.1.13• .1.3.6.1.4.1.94.1.16.4.2.1.1.14• .1.3.6.1.4.1.94.1.16.4.2.1.1.15• .1.3.6.1.4.1.94.1.16.4.2.1.1.16


• net.acl.Acl• net.acl.AclFunction• net.acl.Rule• net.L2Interface• sys.ComputerSystem













PIX sensorThe PIX sensor discovers Cisco PIX devices that are used as IP firewall and network address translationappliances.

The PIX sensor gathers data about the CiscoPIX operating system running on PIX devices. In addition thesensor does the following:

• Discovers all real servers and virtual services running. Real servers are grouped into the real serversgroup.

• Discovers the virtualIp, realIp, virtualPort, and realPort, and derives virtual IPs using them. Virtual IPsare stored in the Vip table.


Sensor name that is used in the GUI and logs• CiscoApplianceVersionSensor• PixSensor

PrerequisiteFor configurations that have multiple context configurations, specify in the discovery scope the IP addressof the "admin context."

LimitationsWhen topologies are displayed, the following limitations apply:

• For context configurations, the virtual and admin contexts are represented by the same icon.• 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.


• cisco.CiscoPixComputerSystem• core.LogicalContent• net.L2Interface• sys.OperatingSystem• vip.RealServer• vip.RealServerGroup• vip.Vip• vip.VipFunction• vip.VirtualService



1. Select Cisco Device as the Component Type.2. Specify the access information (user name, password, and enable password) that TADDM must use for

authentication to the target PIX device.

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

com.collation.pix.pager.commandThis value specifies to use the pager command to force the PIX to return the entire response at once,rather than one screen at a time. Add this entry, if it is not possible to run the configure terminalcommand.

SNMP Light sensorThe SNMP Light sensor supports Level 1 discovery of SNMP network devices.



The SNMP Light sensor gathers the data that is shown in the following tabs of the Details pane:

• General• SNMP Info

The SNMP Light sensor and the SNMP MIB2 sensor gather generic information from the following objectidentifiers (OIDs):

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9 .1.3.6.1.2.1.1.1.0SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System SoftwareIOS (tm) s72033_rp Software (s72033_rp-JK9SV-M), Version 12.2(17d)SXB11, RELEASE SOFTWARE (fc1)Technical Support: http://www.cisco.com/techsupportCopyright (c) 1986-2005 by cisco Systems, Inc.Compiled T

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "Y1UN9;4b/1tz9l#" 10.199.250.9 .1.3.6.1.2.1.1.2.0SNMPv2-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.0SNMPv2-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.0SNMPv2-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.0SNMPv2-MIB::sysLocation.0 = STRING: NC89ACB01

Sensor name that is used in the GUI and logsSnmpLightSensor


• sys.UnitaryComputerSystem• sys.OperatingSystem• sys.SnmpSystemGroup















SNMP MIB2 sensorThe SNMP MIB2 sensor supports Level 2 discovery of SNMP network devices.


The SNMP MIB2 sensor discovers basic SNMP information about the device and other information such asrouter details, bridge details, IP data (both IPv4 and IPv6), and port data. The SNMP MIB2 sensor callsthe Entity MIB sensor and the Bridge SNMP sensor if they are enabled in the discovery profile.

Other sensors are called as the SNMP MIB2 sensor detects the devices that TADDM supports (forexample, the Cisco port sensor and the Cisco VLAN sensor are called if a Cisco device is detected).

The SNMP MIB2 sensor gathers the data that is shown in the following tabs of the Details pane:

• General• SNMP Info• IPv6 Router Details• IPv4 Router Details• IP• Interfaces

The SNMP Light sensor and the SNMP MIB2 sensor gather generic information from the following objectidentifiers (OIDs):

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9 .1.3.6.1.2.1.1.1.0SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System SoftwareIOS (tm) s72033_rp Software (s72033_rp-JK9SV-M), Version 12.2(17d)SXB11, RELEASE SOFTWARE (fc1)Technical Support: http://www.cisco.com/techsupportCopyright (c) 1986-2005 by cisco Systems, Inc.Compiled T

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "Y1UN9;4b/1tz9l#" 10.199.250.9 .1.3.6.1.2.1.1.2.0SNMPv2-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.0SNMPv2-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.0SNMPv2-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.0SNMPv2-MIB::sysLocation.0 = STRING: NC89ACB01

The SNMP MIB2 sensor discovers IPv4 and IPv6 information. Using the IP-MIB and IP-FORWARD-MIBmodules (updated in RFC 4293 and RFC 4292), the sensor collects IP interface, forwarding, and routinginformation. 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)


ipAddressTableThis table lists the IPv4 and IPv6 addresses.

ipAddressPrefixTableThis table lists the prefix information for all addresses.

ipv6IpForwardingThis flag indicates whether the target device is acting as a router to forward IPv6 packets.

ipForwardingThis flag indicates whether the target device is acting as a router to forward IPv4 packets.

inetCidrRouteTableThis IP routing table lists the routes for both IPv4 and IPv6 interfaces.

If the target device supports the necessary versions of the IP-MIB and IP-FORWARD-MIB modules, theSNMP MIB2 sensor collects all the required information, and discovery completes. If the target devicedoes 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 arequeried:

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)

Sensor name that is used in the GUI and logsSnmpMib2Sensor

LimitationsTADDM currently supports a limited number of network devices. In addition, TADDM L2 switches areswitches and L3 switches are routers. So, L3 switches are displayed as a Router in the PhysicalInfrastructure tree and in the Topology.

All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured tobe down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces:

• loopback, for example, 127.0.0.1, 0:0:0:0:0:0:0:1• link-local, for example, 169.254.1.1, FE80:0:0:0:0:0:0:1• multicast, for example, 224.0.0.1, FF00:0:0:0:0:0:0:1• unspecified, for example, 0.0.0.0, 0:0:0:0:0:0:0:0

Therefore, IP networks are not populated in the TADDM user interface.


• net.Bridge• net.IpInterface• net.IpRoute• net.IpV4Address• net.IpV6Address


• net.IpV4Router• net.IpV6Router• net.L2Interface• sys.UnitaryComputerSystem• sys.OperatingSystem• sys.SnmpSystemGroup














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

com.collation.discover.agent.net.SnmpMib2Agent.useEntitySerialWhen you set this property to true, it allows TADDM to collect the Serial Number from EntityMIB.TADDM does not support the allowed Cisco configuration for the chassisId 1.3.6.1.4.1.9.3.6.3. As aresult, an invalid information is set to the SerialNumber attribute for the Network Devices. To avoidthis problem, add thecom.collation.discover.agent.net.SnmpMib2Agent.useEntitySerial=true property tothe collation.properties file.

com.ibm.cdb.discover.sensor.net.snmpmib2.SnmpMib2Sensor.ifTypeThis property is used to create relationships to network devices that use virtual interfaces and arediscovered by the SNMP MIB2 sensor. By default, the sensor does not store virtual interfaces forprocessing. If you want the relationships to virtual interfaces to be displayed in TADDM, add thisproperty to the collation.properties file.The value of this property is the type of the interface of the virtual interface, which is specified by theifType attribute. For example, if an interface has the attribute ifType=135, you must add thefollowing property:

com.ibm.cdb.discover.sensor.net.snmpmib2.SnmpMib2Sensor.ifType=135

You can specify a comma-separated list of the types of the interface as the value of this property.


As a result, the ifType attribute value is treated as a physical port, and the relationship is created.The default value is 6, 62, 69, 117.

com.collation.discover.agent.net.SnmpMib2Agent.isL2InterfaceThis property is used to suppress discovery of an L2 Interface and VLAN interface target.VLANs should work the same as L2 interfaces and have an option to suppress discovery on VLANs, sowe do not confuse devices and have VLANs as Computer System when the computer system shouldbe created based on the Management Interface.In TADDM 7.3 Fixpack 6, TADDM can check if the sysName of the target server and FQDN arematching or not. If it matches, discovery should be continued and if it does not, discovery should bestopped with the warning visible on UI saying discovery stopped as it is a VLAN interface.The following property must be set to true in collation.properties to activate this fix:

com.collation.discover.agent.net.SnmpMib2Agent.isL2Interface=true

Troubleshooting the sensorThis topic describes common problems that occur with the SNMP MIB2 sensor and presents solutions forthose problems.

The SNMP MIB2 sensor is not started, when the session sensor times outProblem

When the session sensor fails because of a timeout, the SNMP MIB2 sensor is not started.

SolutionIf the session sensor times out, the SNMP MIB2 sensor is not started by default. If you want to changethis behavior, set the com.collation.discover.agent.sys.SessionSensor.timeout.snmpproperty to true in the collation.properties file. For details, see “Configuring thecollation.properties file entries” on page 229.

The sensor incorrectly identifies L3 switches as routersProblem

For SNMP devices that TADDM does not already know about, TADDM occasionally misidentifies L3switches as routers.

SolutionUse the SNMP templates to provide TADDM with hints to correctly identify the switches and routers.For information about how to use SNMP templates to assist TADDM with correct switch, routercategorization, see the TADDM User's Guide.

The sensor fails doing an OS discoveryProblem

The sensor fails doing an OS discovery.Solution

Verify the credentials provided in the access list and check to ensure that SNMP is running on theTADDM client.

DataPower device discovered with SnmpMib2Sensor does not merge with datadiscovered by other sensorsProblem

DataPower device that is discovered with SnmpMib2Sensor does not merge with the data that isdiscovered by other sensors.


SolutionWhen DataPower device is configured to use the SNMP protocol, it can be discovered by usingSnmpMib2Sensor. However, DataPower uses a custom set of SNMP OIDs that SnmpMib2Sensor doesnot query. These OIDs are read only by the CustomMib2ComputerSystem sensor with the use ofJython extension script.For more information, see step 6 in the Adding a computer system template for a network device topicin the TADDM User's Guide.To secure proper reconciliation with data stored by DataPower, VMWare and ZEnterprise sensors inDiscovery Management Console, check the following prerequisites:

• Make sure that DataPowerComputerSystem template is enabled in Computer Systems templates(which is the default setting).

• Make sure that CustomMib2ComputerSystem sensor is enabled in the discovery profile that is usedto discover DataPower devices.

• Make sure that the following files are in the TADDM installation:

– etc/templates/commands/DataPowerComputerSystem– etc/templates/commands/extension-scripts/DataPowerComputerSystem.py

Operating system sensorsOperating system sensors discover the operating systems that are running in the environment.

Citrix XenServer sensorThe Citrix XenServer sensor discovers Citrix XenServers. It is script based sensor.

Sensor name that is used in the GUI and logsThe Citrix XenServer sensor is a script-based sensor. It starts after GenericServerSensor. The sensordiscovers a host with the list of virtual machines. Domain 0 is discovered as a virtual machine and itcontains the serial number and UUID that is inherited from servers hardware. Other virtual machines haveserial number and UUID generated by Xen hypervisor.

XenServerSensor

Elements discovered by the sensorThe Citrix XenServer sensor discovers server pools, hosts in a pool, and virtual machines (VM) located onall hosts in a pool.

• The sensor discovers the following elements for pools:

– list of hosts– name

• The sensor discovers the following elements for hosts:

– list of VMs including Domain 0– memory information– CPU information– name– description– running state– UUID

• The sensor discovers the following elements for virtual machines:

– name


– memory information– number of CPUs– power state– PV/HVM– networking information– boot type

PrerequisitesThe following prerequisites are required:

• lsof must be installed in Domain 0• xapi must be running in Domain 0• For Linux-based VM, guest tools must be running in Paravirtualized DomainU to discover such virtual

machine.• For Windows-based VM, guest tools must be running in Hardware Virtual Machine to discover network

and OS information.


• simple.SLogicalGroup• sys.ComputerSystem• sys.linux.Linux• sys.linux.LinuxUnitaryComputerSystem• sys.windows.WindowsComputerSystem• sys.windows.WindowsOperatingSystem

Troubleshooting the sensorThis topic describes common problems that occur with the Citrix XenServer sensor and presents solutionsfor those problems.

Windows virtual machine is discovered as Other Computer system with no OSinformationProblem

Windows virtual machine is discovered as Other Computer system and no OS information is provided.Solution

Check whether the guest tools are running in the virtual machine. The tools are required for discovery.

Linux virtual machine is not discovered.Problem

Linux virtual machine is not discovered and a warning is displayed.Solution

Check whether the guest tools are running in the virtual machine. The tools are required for discovery.


DataPower sensorThe DataPower sensor discovers IBM WebSphere DataPower SOA Appliances, which support SOAPConfiguration Management interface.

In TADDM 7.3.0.3, and later, the sensor discovers DataPower domains and the following types of proxies:

• SSL Proxy• TCP Proxy• XSL Proxy• WS Proxy• Multi-Protocol Gateway (MPG)• XML Firewall• HTTP Service

The discovered data is stored as extended instances. For each new discovered category, a separate tab iscreated in Data Management Portal, for example the Domains, or SSL Proxy tabs. The data is displayed inthe XML format.

Sensor name that is used in the GUI and logsDataPowerSensor

PrerequisitesThe discovered DataPower appliances must have SOAP Configuration Management service enabled.


• sys.appliance.DataPower• net.L2Interface• net.IpInterface


Configuring port numbersYou must set a port number of the DataPower SOAP Configuration Management interface in the portsensor configuration.

1. Create a discovery profile.2. Select PortSensor from the sensor list and click New.3. In the dataPowerXmlManagementPorts field, enter a comma-separated list of port numbers, which

are to be treated as DataPower SOAP Configuration Management interface ports. Specify otherrequired information, enable the configuration, and save it.

4. Add DataPowerSensor to your discovery profile and save it.

When you run a discovery by using the profile that you created, the DataPower sensor is started for eachserver, which listens on any of the ports that are provided in the dataPowerXmlManagementPorts list.


Configuring the access list and certificatesThe DataPower sensor requires the appropriate entry of the "DataPower" component type in the accesslist. The user name and password must be the same as when logging to your DataPower appliance withWebGUI or SSH.

Certificate setupThe DataPower sensor uses HTTPS protocol and requires a truststore file with your appliance certificate,which must be attached to the access list entry. Each access list entry uses its own truststore file and isindependent of other entries from the access list.

You can use the iKeyman utility (ikeyman.exe on Windows) to create a truststore file. The utility isincluded in the TADDM installation. Certificates from your DataPower appliance or appliances must beadded to your truststore file as signer certificates.

Ignoring certificates validationIf your environment is fully trusted, you can configure the DataPower sensor to ignore the certificatesvalidation.

1. Choose the discovery profile used for your DataPower appliances discovery.2. Select DataPowerSensor from the sensor list and click New.3. Change the value of the validateCertificates property to false, enable the configuration, and

save it.4. Save the discovery profile.

When you run a discovery by using the profile that you created, the DataPower sensor does not validatecertificates, so you do not have to attach any truststore files to your DataPower access list entries.

Enabling host name verificationWhen you use FQDN-based certificates, the host name verification step of SSL protocol is bypassed due toTADDM scope definition restrictions. When you use IP-based certificates, you can enable the host nameverification to fully secure the SSL connection.

TADDM scope definition is IP-address-based, not FQDN-based. Any FQDN value that is provided duringthe scope creation is immediately resolved to the IP address. The FQDN is not passed to the sensor whenrunning the discovery. The sensor must use the IP address when trying to connect to the Data Powerappliance. When the Data Power appliance certificate is FQDN-based, normally the SSL protocol error israised to indicate a possible mismatch between the provided IP address and the FQDN of the service readfrom the certificate. To avoid this problem, the host name verification step is disabled by default.

When you use IP-based certificates, you can enable the host name verification step to fully secure the SSLconnection.

1. Choose the discovery profile used for your DataPower appliances discovery.2. Select DataPowerSensor from the sensor list and click New.3. Change the value of the bypassHostnameVerification property to false, enable the

configuration, and save it.4. Save the discovery profile.

When you run a discovery by using the profile that you created, the DataPower sensor is strictly compliantwith SSL protocol. The IP address provided on the TADDM scope must exactly match the IP addressstated in the certificate of the Data Power appliance for the discovery to be successful.


Troubleshooting the sensorThis topic describes common problems that occur with the DataPower sensor and presents solutions forthose problems.

DataPower device discovered with SnmpMib2Sensor does not merge with datadiscovered by other sensorsProblem

DataPower device that is discovered with SnmpMib2Sensor does not merge with the data that isdiscovered by other sensors.

SolutionWhen DataPower device is configured to use the SNMP protocol, it can be discovered by usingSnmpMib2Sensor. However, DataPower uses a custom set of SNMP OIDs that SnmpMib2Sensor doesnot query. These OIDs are read only by the CustomMib2ComputerSystem sensor with the use ofJython extension script.For more information, see step 6 in the Adding a computer system template for a network device topicin the TADDM User's Guide.To secure proper reconciliation with data stored by DataPower, VMWare and ZEnterprise sensors inDiscovery Management Console, check the following prerequisites:

• Make sure that DataPowerComputerSystem template is enabled in Computer Systems templates(which is the default setting).

• Make sure that CustomMib2ComputerSystem sensor is enabled in the discovery profile that is usedto discover DataPower devices.

• Make sure that the following files are in the TADDM installation:

– etc/templates/commands/DataPowerComputerSystem– etc/templates/commands/extension-scripts/DataPowerComputerSystem.py

FreeBSD computer system sensorThe FreeBSD computer system sensor discovers computer systems that run the FreeBSD operatingsystem, which is based on BSD UNIX.

Sensor name that is used in the GUI and logsFreeBSDComputerSystemSensor

PrerequisitesFor the sensor to discover the operating system, the /bin/sh script must be configured as a default shell.

To successfully merge with data that is discovered by the VMware ESX computer system sensor, thedmidecode command is required on the targets where you have the FreeBSD operating system installed.

LimitationsAll computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured tobe down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces:




If the following command is present on the target system, the sensor discovers the local file systems:

df -kTP

Discovery of IPv6 interfaces and IPv6 routing and forwarding informationThe sensor discovers IPv6 interfaces and IPv6 routing and forwarding information about target systemsthat are configured to support IPv6. TADDM runs discoveries against only IPv4 addresses. TADDM doesnot start a sensor against IPv6 addresses. For DNS lookups, TADDM uses either the IPv4 or the IPv6addresses. TADDM does not populate the net.IpNetwork attribute on an IPv6 interface if the prefix lengthvalue is unspecified or equals zero.

The discovered IPv6 addresses are displayed in the TADDM user interface similarly to IPv4 addresses andare accessible using the TADDM API. Because IPv6 addresses use a prefix length value instead of an IPv4netmask, only one of these values is populated for an IP address. The value depends on the address type.

Asynchronous and script-based discovery supportThe FreeBSD computer system sensor supports script-based discovery.

Sensor configuration requirementsFor information about configuring for script-based discovery, see the Configuring for script-baseddiscovery topic in the TADDM Administrator's Guide.

Access list configuration requirementsFor script-based discovery, the access list configuration is the same as for nonscript-based discovery.

Model objects with associated attributesThe FreeBSD computer system sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about computer systems running the FreeBSDoperating system in your IT environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.core.LogicalContent

• Checksum• Content• FixedPath• URI

net.L2Interface

• Promiscious• Name• HwAddress• Mtu• Speed• Duplex• AutoNegotiation• Broadcast• Loopback• InterfaceMTU


• InterfaceName

net.IpInterface

• IpAddress• L2Interface• IpNetwork

sys.DNSResolveEntry

• ServerIp• SearchOrder

sys.freebsd.FreeBSD

• FQDN• Name• OSName• OSVersion• BootTime• KernelArchitecture• KernelVersion• WordSize• Charset• OsId• OSMode• OSConfidence• VersionString• KernelModulesRawData

sys.freebsd.FreeBSDUnitaryComputerSystem

• UUID• Name• Type• SystemId• Signature• Fqdn• SerialNumber• Manufacturer• Model• MemorySize• BIOSManufacturer• BIOSDate• BIOSName• NumCPUs• CPUType• CPUSpeed• Architecture• TimeZone


• VirtualMachineState

sys.SoftwareComponent

• SoftwareVersion• Name

sys.unix.UnixFileSystem

• MountPoint• Type• Capacity• AvailableSpace• Owner• Group• Permissions




1. Select ComputerSystem as the component type.2. Specify the access information (user name and password) that TADDM must use for either SSH key-

based authentication or SSH login-based authentication to the target computer system.

Typically, an account with non-root privilege can be used. However, some commands that TADDM usesduring the discovery process might require privilege escalation, which can be done using the sudocommand.

For more information, see the Commands that might require elevated privilege topic in the Administrator'sGuide.



com.ibm.cdb.discover.sys.freebsd.pkg_info=pkg_infoThis property specifies the path to the pkg_info command on the FreeBSD operating systemversions 9.x, or earlier. The command provides the information about all installed packages on theFreeBSD operating system.The default value is pkg_info.

com.ibm.cdb.discover.sys.freebsd.pkg_info_10=pkg infoThis property specifies the path to the pkg info command on the FreeBSD operating systemversions 10.x, or later. The command provides the information about all installed packages on theFreeBSD operating system.The default value is pkg info.


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

Duplicate FreeBSD guests are createdProblem

When the same guest that has the FreeBSD operating system installed is discovered by the FreeBSDcomputer system sensor and the VMware ESX computer system sensor, the data is not merged andduplicates are created.

SolutionInstall the dmidecode command on the targets where you have the FreeBSD operating systeminstalled. This command is required to successfully merge with data that is discovered by the VMwareESX computer system sensor.

HP BladeSystem SNMP sensorThe HP BladeSystem SNMP sensor discovers and collects configuration information about HPBladeSystem chassis.

The sensor uses SNMP (Simple Network Management Protocol) to discover and query BladeSysteminfrastructure components. HP BladeSystem Onboard Administrator SNMP component is used to collectthe data.

Sensor name that is used in the GUI and logsHPBladeSystemSnmpSensor


• enums.PhysTypeEnum• enums.SlotStateEnum• enums.BladeCenterManagementModuleTypeEnum• net.Fqdn• phys.physconn.PhysicalConnector• phys.physconn.Slot• phys.physpkg.Board• phys.physpkg.Chassis• phys.physpkg.Fan• phys.physpkg.PhysicalFrame• phys.physpkg.PowerSupply• sys.blade.BladeCenterManagementModule• sys.ComputerSystem• storage.FCSwitch




You can configure the HP BladeSystem SNMP sensor in the Discovery Management Console by setting thefollowing attributes:snmpPort

The port number used for SNMP communication. The default value is 161.snmpTimeout

The timeout used for a single SNMP query. The default value is 20000.locale

The locale used for SNMP queries.characterEncoding

The character encoding used for SNMP queries.

When the HP BladeSystem SNMP sensor is enabled, you must also enable the SNMP Light sensor orSNMP MIB2 sensor for the HP BladeSystem SNMP sensor to function correctly.



• For SNMP V1 and V2 discovery, enter the correct Community String into the access list.

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

• For SNMP V3 discovery, enter the correct user name, password, and authentication protocol into theaccess list, according to the SNMP V3 credential mapping information in the following table.

Table 23. SNMP V3 credential mapping.


Authentication type (for example MD5) Authentication Protocol



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

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

An SNMP time out error occursProblem

The sensor generates an SNMP time out error during a discovery.Solution

Increase the value of the snmpTimeout parameter for the HP BladeSystem SNMP sensor by using theDiscovery Management Console.


HP Blade System objects do not reconcile with Level 2 discovery dataProblem

Discovery of HP Blade System creates Computer Systems that do not reconcile with the Level 2discovery data when Virtual Connect has logical server profiles enabled.

SolutionTADDM inspects objects that come from HP Blade System discovery, when the default attributesmanufacturer, model and serialNumber do not match. The logic inside reconciliation plug-inrequires that the manufacturer, model, and FQDN attributes are the same as the data found duringthe Level 2 discovery to enable reconciliation of both objects. If FQDN is not available, two instancesof the same object appear in the database.

HP NonStop computer system sensorThe HP NonStop computer system sensor discovers the computer system that runs the HP NonStop OSSoperating system. The sensor works only in Asynchronous discovery mode.

Sensor name that is used in the GUI and logsHpNonStopComputerSystemSensor

PrerequisitesA discovery user needs to have access to both OSS and Guardian environment. An ASD script is executedfrom OSS environment.

You can create an ASD package with following command:

$COLLATION_HOME/bin/makeASDScriptPackage.sh --outputDir output dir --uname NONSTOP_KERNEL --ipAddress ip_address --packingMethod tar --sensors computersystem

LimitationsThe 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 startsLevel 3 sensors is not supported on the HP NonStop platform.


• core.LogicalContent• sys.hpnonstop.HpNonStop• sys.hpnonstop.HpNonStopComputerSystem

Asynchronous discovery supportThe HP NonStop computer system sensor supports asynchronous discovery.




Troubleshooting the sensorProblems with the sensor might include unsuccessful discovery or incorrectly defined properties.However, you can recover from these problems.

General problemsVerify that the following sensors are enabled in the profile:

• ASDPingSensor• ASDSensor• GenericComputerSystemSensor• HpNonStopComputerSystemSensor

Verify that the ASD packages are available for a discovery in a directory defined by propertycom.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory.

HP-UX computer system sensorThe HP-UX computer system sensor discovers a computer system that is running the HP-UX operatingsystem. If a system is running HP-UX on an Itanium platform with virtualization support (HP IntegrityVirtual Machines), the sensor discovers elements that are managed by the server.

Sensor name that is used in the GUI and logsHpUxComputerSystemSensor

PrerequisitesFor a VM Host system on an Itanium platform, the TADDM service account must have Execute permissionson the hpvmstatus and hpvminfo binary files.

For a guest system on an Itanium platform, the TADDM service account must have Execute permissionson the hpvminfo binary files.

The TADDM service account must have Execute permissions on the machinfo binary files.




The following limitations when discovering CPU information through the HP-UX Computer System sensorapply:

• The sensor doesn't discover 'CPUCoresInstalled' for PA-RISC architecture.• The sensor doesn't discover threads number for CPU - HyperThreading configuration.• The sensor doesn't discover 'CPUDiesInstalled' if command 'mpsched -K' is unavailable.• The sensor doesn't discover 'CPUCoresInstalled' if command 'icapstatus' is unavailable.• The sensor doesn't discover cpu/cores configuration if command 'mpsched -K' is unavailable.


Discovery of IPv6 address of a guest system through a VM Host is not available for HP-UX on an Itaniumplatform. Discovery of IPv6 address of a VM Host through a guest system is not available for HP-UX on anItanium platform.

Guest systems that are running non-HP-UX operating systems are not created during discovery of the VMhost systems.

TADDM is unable to discover CPU cores information of IVM guest, which is directly discovered by thesensor. This happens because the icapstatus command is not supported on the IVM guest.




• core.LogicalContent• sys.hpux.HpUx• sys.HpUxUnitaryComputerSystem• sys.OperatingSystem• sys.SoftwareComponent

Model objects with associated attributesThe HP-UX computer system sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about HP-UX computer system resources in yourIT environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.sys.hpux.HpUxUnitaryComputerSystem

• Name• UUID• Type• SystemId• VirtualMachineState• Signature• Fqdn• Manufacturer• Model• MemorySize• NumCPUs• CPUType• CPUSpeed


• Architecture• Virtual• CPUDiesInstalled• CPUCoresInstalled• ChildSystem• VMID

sys.CPU

• IndexOrder• CPUType• NumCPUs• CPUSpeed• CPUCoresEnabled• CPUCore• Virtual

sys.hpux.HpUx

• Fqdn• Name• OSName• OSVersion• BootTime• PatchesInstalledRawData• KernelVersion• OsId• KernelModulesRawData• OSConfidence• VersionString

core.LogicalContent

• Checksum• Content• URI• fixedPath


• Name• SoftwareVersion


• AvailableSpace• Capacity• MountPoint

net.L2Interface

• IANAInterfaceType• interfaceMTU• interfaceSpeed


• interfaceName• HwAddress• Mtu• Name• Speed• Loopback• Broadcast• Encapsulation

net.IpInterface




The HP-UX computer system sensor can be run using the ComputerSystem access credentials. Toconfigure the access list, complete the following steps:



Typically, an account with non-root privilege can be used. However, some commands that TADDM usesduring the discovery process can require privilege escalation. Typically, this escalation is done using thesudo command.




com.collation.platform.os.command.machinfoThis property specifies the path to the machinfo command. If this property is not set, the defaultvalue of /usr/contrib/bin/machinfo is used.

com.collation.discover.agent.command.kcmoduleThis property specifies the path to the kcmodule command.

com.collation.platform.os.HpUxItanium.ModelUsed as a starting point for HpUx on Itanium. The default value is ia64. Change this property when themodel command on HP-UX Itanium systems does not contain ia64 in the output.

com.collation.discover.agent.command.hpvminfoThis property specifies the path to the hpvminfo command. If this property is not set, the defaultvalue of /opt/hpvm/bin/hpvminfo is used.

com.collation.discover.agent.command.hpvmstatusThis property specified the path to the hpvmstatus command. If this property is not set, the defaultvalue of /opt/hpvm/bin/hpvmstatus is used.


com.collation.platform.os.command.crontabEntriesCommand.HP-UX=crontab -lThis property is used to discover crontab entries. You can specify this property as a scoped propertyby appending an IP address or a scope set name to the property. The following example uses anappended IP address:

com.collation.platform.os.command.crontabEntriesCommand.HP-UX.1.2.3.4=crontab -l

com.collation.platform.os.command.crontabEntriesUsers.HP-UX=rootThis property is used to discover crontab entries for a specified user, use a comma-separated list tospecify more than one user. You can specify this property as a scoped property by appending an IPaddress 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

com.collation.discover.agent.sys.ComputerSystem.serialNumberSanityChecks="ˆ(?!null);ˆ(?!not );ˆ(?!n/a);ˆ(?!permission);ˆ(?!to be );ˆ(?!undef);ˆ[ -:\.\w]{4,80}$; ^(?!.{8}(\-.{4}){3}\-.{12}_.{2}(:.{2}){5});^(?!none);^(?!x{7});^(?!\.{9});^(?!0123456789);^(?!0+$)";

This property is used to validate the serialNumber property that is discovered by the operating systemsensors, except Solaris, to avoid storing generic values, such as Not Defined, To be set by OEM, orPermission Denied.

The main default rule is that a serial number must contain from 4 to 80 characters and not begin withone of the following strings:

• null : regular expression ^(?!null)• not : regular expression ^(?!not)• n/a : regular expression ^(?!n/a)• permission : regular expression ^(?!permission)• to be : regular expression ^(?!to be)• undef : regular expression ^(?!undef)• string in form : 098D8710-E623-3C3B-9F9B-FCBAFF1BF3B6_5C:F3:FC:E8:89:FC : regular

expression ^(?!.{8}(\-.{4}){3}\-.{12}_.{2}(:.{2}){5})• none : regular expression ^(?!none)• xxxxxxx : regular expression ^(?!x{7})• ......... : regular expression ^(?!\.{9})• 0123456789 : regular expression ^(?!0123456789)• 0000 : regular expression ^(?!0+$)

If a serial number does not follow this rule, it is not set. The regular expression syntax is defined in theJava SDK for class java.util.regex.Pattern. Regular expressions must be separated bysemicolons. Candidate serial numbers are always converted to all lowercase before they are matchedagainst the regular expressions. Therefore, when you customize the property, use lowercasecharacters only.

Troubleshooting the sensorThis topic describes common problems that occur with the HP-UX computer system sensor and presentssolutions for those problems.

General problemsVerify that the attributes, such as Architecture, processor type, processor speed, Memory size, or Serialnumber, 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 toinclude the unique identifier from the model command output.

The Serial number attribute is not populated on Itanium by default. To enable the Serial number attribute,add the following entry in the collation.properties file on the TADDM server:

com.collation.discover.agent.sys.HpUxComputerSystemItaniumAgent.setSerialNumber=true

Hardware details are not displayedProblem

During a discovery through IBM Tivoli Monitoring, certain detailed information is not displayed forcomputer systems running the HP-UX operating system.

SolutionIn the collation.properties file, add the |.*machinfo.* pattern to the end of the property:

com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*machinfo.*

IBM AIX computer system sensorThe IBM AIX computer system sensor discovers computer systems that run the IBM AIX operatingsystem. In addition, workload partitioning (WPAR) in the IBM AIX 6.1 operating system is discovered bythe sensor.

Sensor name that is used in the GUI and logsAixComputerSystemSensor

PrerequisitesThe TADDM user must have an access to the entstat command on AIX target systems.

In a system P or a system Z computer system environment, the LPAR ID should be saved in the VM IDattribute, to avoid the incorrect merging of different LPARs to a single object.

For AIX, the VMID attribute has been changed from LPAR ID (numeric) to LPAR name (text). VMID andLPAR must be set as True.




The sensor discovers WPARs by using the WPAR name and IP address. After running a discovery, if the IPaddress 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. Thislimitation does not apply to WPARs where the IP address is not configured.

The fully qualified domain name (FQDN) can be obtained for the WPAR from the host name. In this case,TADDM does not request the host name from the DNS server and the name is not displayed.

Information about the attributes virtual memory size and page space for the WPAR is not discovered.


The WPAR mobility function that allows you to move running WPAR instances between physical systemsis not supported.

Live Partition Mobility (LPM) is not supported in TADDM 7.3.0. It is supported in 7.3 Fix Pack 1,and later.



Asynchronous and script-based discovery supportThe IBM AIX computer system sensor supports asynchronous and script-based discovery.


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



LimitationsComputer system templates and extensions are not supported by the AIX computer system sensor duringasynchronous or script-based discovery.

Model objects with associated attributesThe IBM AIX computer system sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about computer systems running the IBM AIXoperating system and workload partitioning (WPAR) resources in your IT environment.


• Checksum• Configfile• Content• ContentType• FixedPath• URI

net.L2Interface

• AlternativeName


• AutoNegotiation• Broadcast• Duplex• Encapsulation• HwAddress• InterfaceMTU• InterfaceName• Loopback• Mtu• Name• Promiscious• Speed• IANAInterfaceType• Index

net.IpInterface


sys.aix.Aix

• BootTime• Charset• FQDN• KernelModulesRawData• KernelVersion• Name• OSConfidence• OsId• OSMode• OSName• OSVersion• PatchesInstalledRawData• VirtualMemorySize• WordSize• VersionString• Level• BuildLevel• ServicePack

sys.aix.AixUnitaryComputerSystem

• Architecture• BIOSManufacturer• CPUSpeed• CPUType• DesiredProcessingUnits


• Fqdn• IsVMIDanLPAR• Manufacturer• MaxProcessingUnits• MemorySize• MinProcessingUnits• Model• Name• NumCPUs• SerialNumber• Signature• SystemId• TimeZone• Type• Virtual• VMID• VirtualMachineState• ChildSystem

sys.AixSoftwareComponent

• InstallState• Name• SoftwareVersion• Type

sys.CPU

• IndexOrder• CPUType• NumCPUs• CPUSpeed• Virtual

sys.DNSResolveEntry

• SearchOrder• ServerIp


• AvailableSpace• Capacity• Group• MountPoint• Owner• Permissions• Type

sys.PageSpace

• IsActive


• Name• Size• Type

sys.WPARComputerSystem

• AssignedIp• IsWparActive• IsWparAutostart• IsWparCheckpointable• WparCPULimits• WparCPUShares• WparInstalledDirectory• WparMemoryLimits• WparMemoryShares• WparOwner• WparPerProcessVirtualMemoryLimit• WparType• Name• Type• Virtual


Edit the /etc/sudoers file on the AIX server and add the following line:

<TADDM_USER> ALL=NOPASSWD: ALL



1. Use ComputerSystem as the Component Type.2. Specify the access information (user name, password) that TADDM must use for either SSH key-based

authentication or SSH login-based authentication to the target computer system.

Typically, an account with non-root privilege can be used. However, some commands that TADDM usesduring the discovery process can require privilege escalation. This escalation, can be done using the sudocommand.


Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the IBM AIX computer system sensor uses.

The sensor uses the following entry in the collation.properties file:com.collation.discover.agent.command.lswpar.AIX=sudo lswpar

The lswpar command requires administration privileges.


com.collation.platform.os.command.crontabEntriesCommand.AIX=crontab -lThis property is used to discover crontab entries. You can specify this property as a scoped propertyby appending an IP address or a scope set name to the property. The following example uses anappended IP address:

com.collation.platform.os.command.crontabEntriesCommand.AIX.1.2.3.4=crontab -l

com.collation.platform.os.command.crontabEntriesUsers.AIX=rootThis property is used to discover crontab entries for a specified user, use a comma-separated list tospecify more than one user. You can specify this property as a scoped property by appending an IPaddress 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







Troubleshooting the sensorThis topic describes common problems that occur with the IBM AIX computer system sensor andpresents solutions for those problems.

Sensor does not discover WPARsProblem

The sensor is not able to discover WPAR.Solution

To check the status of the WPAR:


1. Run the sudo lswpar command using the <TADDM_User> credentials. If a list of WPARs is notdisplayed, assign to the <TADDM_User> administrator credentials to run the lswpar command.

2. Modify the sudo specific command in the collation.properties file.

Discovered WPARs do not display attribute valuesProblem

Some of the discovered WPARs do not display attribute values.Solution

Verify if the WPARs present are in an active or defined state. For WPARs that are in a defined state, alimited number of attribute values are displayed.

IBM Hardware Management Console sensorThe IBM Hardware Management Console sensor discovers the IBM Hardware Management Console(HMC) and its managed systems.

Sensor name that is used in the GUI and logsHmcSensor

Resources discovered by the sensorThe process for discovering an HMC is like discovering a standard computer system. The most importantissues that impact discovery is connectivity and authentication. If the account configured in the TADDMaccess list can connect to the HMC, the discovery is successful.

Through the HMC, the following resources can be discovered:

• HMC, the hardware management console.• The systems managed by the HMC (System p and System i® computer systems).• The logical partitions (LPARs) defined within each managed system.• If an LPAR is installed with the Virtual I/O Server (VIOS), the VIOS is discovered.

Depending on the discovery scope, discovering a computer system (LPAR) can discover two instances ofthe computer system:

• The computer system (LPAR) discovered by the HMC sensor.• The computer system discovered by the normal TADDM sensor for the particular operating system, such

as Linux or AIX, among others.

This instance is discovered just as a physical Linux or AIX computer system. There are no specialTADDM sensors to discover these virtual computer systems any differently than the physical computersystems they emulate.

The computer system (LPAR) discovered by the HMC is a shallow computer system. The following keyattributes, which form the naming rule, are discovered:

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

• Virtual SCSI adapters• Virtual NPIV adapters


• Virtual target devices• Physical volumes• MPIO paths• HBAs

You must use the Hmcoperator user to discover storage mapping information.

VIOS is discovered with the following network mapping information:

• Virtual adapters• Physical adapters• Shared ethernet adapters

With the discovery of HMC and the storage sensor discovery of LPARs, you can see a mapping betweenthe LPAR disk and the virtual target device of a VIOS.

Limitations Live Partition Mobility (LPM) is not supported in TADDM 7.3.0. It is supported in 7.3 Fix Pack 1,

and later.

Model objects with associated attributesThe IBM Hardware Management Console sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about IBM Hardware ManagementConsole (HMC) and its managed systems in your IT environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.app.SoftwareFix

• ControlSoftware

dev.FCPort

• DeviceID• TotalNpivPorts• AvailableNpivPorts• Parent• Description• PhysicalLocationCode• Status• PermanentAddress• ChildPorts• SecondaryAddress

dev.BasedOnExtent

• Source• Target

dev.MediaAccessDevice

• Manufacturer• Model• Name• SerialNumber


• Status• Type

dev.SCSIProtocolController

• Name• Parent• PhysicalLocationCode• Client• ServerSlotNumber• TargetDevices• ClientSlotNumber• ObjectType• Description• EndPoints

dev.SCSIProtocolEndPoint

• Name• Parent• Description

dev.StorageVolume

• Name• Parent• Type• IeeeUniqueVolumeName• Capacity• LUN• Pvid• NumStalePartitions• SerialNumber• SystemPState• ViosUDID• VolumeGroupName• BasedOn• MpioPaths

dev.vios.MpioPath

• Controller• Volume• Connection• Status

dev.vios.NpivViosVirtualAdapter

• ClientStatus• FcPorts

dev.vios.VirtualTargetDevice

• BackingDevice


• Status

net.L2Interface

• AlternativeName• DefaultVlan• HaMode• HwAddress• Index• IsIEEE8021QCompatible• IsTrunk• Name• NetworkedFromVlan• Parent• SwitchPortMode• TrunkPriority• ViosType

net.Vlan

• Interfaces• MgmtDomainName• VlanId• VlanName

sys.ComputerSystem

• CPUCoresEnabled• CPUCoresInstalled• CPULimit• CPUSpeed• CPUType• ChildSystem• ContextIp• Description• DesiredHugePages• DesiredMemorySize• DesiredProcessingUnits• DesiredProcessors• Devices• DisplayName• FileSystems• Fqdn• Functions• Guid• HostSystem• IpInterfaces• IsVMIDanLPAR• L2Interfaces


• Label• ManagedSystemName• Manufacturer• MaxHugePages• Memory• MemoryLimit• MemorySize• MinHugePages• Model• Name• NumCPUs• OSInstalled• OSRunning• ObjectType• PrimaryMACAddress• SerialNumber• Signature• StorageExtent• SystemId• Type• UncappedWeight• VMID• Virtual

sys.ControlSoftware

• BuildLevel• ContextIp• DisplayName• Fixes• Level• MajorVersion• Modifier• Name• Release• VersionString

sys.FileSystem

• Parent• MountPoint

sys.Function

• Name• Parent

sys.HMC

• Systemp


sys.LocalFileSystem

• StorageExtent

sys.SystemPComputerSystem

• Architecture• AvailableSysProcUnits• CPUCoresEnabled• CPUCoresInstalled• CPUSpeed• CPUType• ConfigurableNumSysHugePages• ConfigurableSysProcUnits• ConfigurableSystemMemory• DeconfiguredSysProcUnits• DeconfiguredSystemMemory• HugePageSize• Is5250ApplicationCapable• IsCoDMemoryCapable• IsCoDProcessorCapable• IsI5OSCapable• IsLHCACapable• IsLHEACapable• IsMicroPartitioningCapable• IsSNIMsgPassingCapable• IsVIOSCapable• Manufacturer• MaxNumProcessorsPerLPAR• MaxsSharedProcessorPools• MemoryAvailableForPartitions• MemorySize• MinProcessingUnitsPerVirtualProcessor• Model• SerialNumber


Configuring the discovery profileBy default, the IBM Hardware Management Console (HMC) sensor is enabled for a Level 2 or Level 3discovery. The sensor discovers all logical partitions (LPARs) regardless of whether the system is running.To discovery LPARs only when the system is running, create a Level 2 or Level 3 discovery profile for theIBM Hardware Management Console (HMC) sensor, and customize the sensor settings.


1. In the Discovery drawer of the Discovery Management Console, click Discovery Profiles.2. In the Discovery Profiles window, click New.


3. In the Create New Profile window, type the profile name and description. From the Clone existingprofile list, select Level 2 Discovery, or Level 3 Discovery, and click OK.

4. On the Sensor Configuration tab, select the HmcSensor sensor.5. In the Create Configuration window, type the name and description for your configuration, and select

the Enable Configuration check box.6. In the Configuration section of the Create Configuration window, click discoverNonRunningLpars.

Then double-click the Value field in the row, and type false.7. Click OK to return to the Discovery Profiles window.8. In the Discovery Profiles window, click Save.



1. Select ComputerSystem as the Component Type.2. Specify the following required information:

a. Username.

This username should have (at a minimum) the authorizations mentioned below.b. Password

From the HMC management console, create a user account for the TADDM discovery user. The useraccount must be based on the hmcoperator role.

In addition, the following command line tasks must be assigned to the user account:

Managed SystemRequired to use the lshwres and lssyscfg commands

Logical PartitionRequired to use the lshwres, lssyscfg, and viosvrcmd commands

HMC ConfigurationRequired to use the lshmc command

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

You can set the following entries in the collation.properties file:com.collation.discover.agent.HmcSensor.timeout

This property specifies the time, during which the sensor is allowed to run the discovery. If theamount of the retrieved data about the storage is too great, the sensor might not complete within thespecified time. To collect all the details, increase the value of this property.The value of this property is expressed in milliseconds.

com.collation.discover.agent.HMC.discoverStorageMapping=trueThis property is used to provide all the details regarding the retrieved data. If you are not interested incollecting all the details, set this property to false, and decrease the value of thecom.collation.discover.agent.HmcSensor.timeout property.The default value of this property is true.This property is a scoped property, you can append the IP address or name of the scope to thisproperty.

ExamplesThe following examples show the retrieved information, when thecom.collation.discover.agent.HMC.discoverStorageMapping=true property is set in thecollation.properties file. The examples apply to the AIX operating system.


discoverDevicesThe command to get the information:

viosvrcmd -m '{0}' --id '{1}' -c 'lsdev -field name status physloc description parent -state 1 -fmt ::'

discoverPhysicalVolumesThe command to get the information:

viosvrcmd -m '{0}' --id '{1}' -c 'lspv -size -fmt ::'

discoverVirtualScsiServerAdaptersThe command to get the information:

viosvrcmd -m '{0}' --id '{1}' -c 'lsmap -all -field svsa physloc clientid vtd status lun backing -fmt ::'

IBM Integrated Virtualization Manager sensorThe IBM Integrated Virtualization Manager sensor discovers IBM POWER processor-based systemsmanaged by an Integrated Virtualization Manager (IVM).

Sensor name that is used in the GUI and logsIvmSensor

Resources discovered by the sensorThe process for discovering an IVM is like a standard computer system. The most important issues thatimpact discovery is connectivity and authentication. If the account configured in the TADDM access listcan connect to the IVM, the discovery is successful.

Through the IVM, the following resources can be discovered:

• The integrated management console.• The system managed by the IVM (System p or System i computer systems).• The logical partitions (LPARs) defined within the managed system.

Depending on the discovery scope, discovering a computer system (LPAR) can actually discover twoinstances of the computer system:

• The computer system (LPAR) discovered by the IVM sensor.• The computer system discovered by the normal TADDM sensor for the particular operating system, such

as Linux or AIX, among others.

This instance is discovered just like a physical Linux or AIX computer system. There are no special TADDMsensors created to discover these virtual computer systems any differently than the physical computersystems they emulate.

The computer system (LPAR) discovered by the IVM is a shallow computer system. The following keyattributes, which form the naming rule, are discovered:

• Manufacturer• Model• Serial number• LPAR ID, which are naming rule attributes.

After discovery, TADDM merges the two instances into a single computer system.



• sys.ComputerSystem• sys.ControlSoftware• sys.IVM• sys.SystemPComputerSystem• sys.VIOS




1. Select ComputerSystem as the Component Type.2. Specify the following required information:

a. User name.b. Password

From the IVM management console, create a user account for the TADDM discovery user with the ViewOnly role.

IBM i computer system sensorThe sensor discovers the IBM i operating system, which is used on the IBM Power Systems family ofservers and is the next generation of the IBM i5/OS operating system and the IBM OS/400 operatingsystem.

Sensor name that is used in the GUI and logsI5OSComputerSystemSensor

PrerequisitesThe sensor requires the following software to be installed and operational:

• IBM Portable Utilities for i, which provides OpenSSH and OpenSSL for IBM i.• Qshell, which is a standards-based command interpreter that enables a common development

environment.• 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.• 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:

• IBM Portable Utilities for i: 5733SC1 *BASE and option 1 (V7R1M0)• Qshell: 5770SS1 option 30• PASE: 5770SS1 option 33

Note: In IBM i 7.1, the licensed program product JC1 (IBM Toolbox for Java) is no longer provided as aseparate 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:


• IBM Portable Utilities for i: 5733SC1 *BASE and option 1 (V6R1M0)• Qshell: 5761SS1 option 30• PASE: 5761SS1 option 33• IBM Toolbox for Java: 5761JC1

For IBM i 5.4 and i5/OS V5R3, you need the following versions of the required software:

• IBM Portable Utilities for i5/OS: 5733SC1 *BASE and option 1• Qshell: 5722SS1 option 30• PASE: 5722SS1 option 33• IBM Toolbox for Java: 5722JC1




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 auser name and a password.


• core.LogicalContent• dev.MediaAccessDevice• sys.i5OS.I5OperatingSystem• sys.i5OS.I5OSSoftwareComponent• sys.i5OS.I5Profile


Sufficient access privileges are required that allow users to discover the system:

• Privilege class: User• System privileges:

– All object access is required to discover all user profiles on the system.– Save/restore

IPSO computer system sensorThe IPSO computer system sensor discovers Nokia firewall devices running the IPSO operating system.

Sensor name that is used in the GUI and logsIPSOComputerSystemSensor






• core.LogicalContent net.Firewall• sys.Function• sys.ipso.ipso• sys.ipso.IPSOUnitaryComputerSystem



1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM should use for either SSH key-

based authentication or SSH login-based authentication to the target system.

Linux computer system sensorThe Linux computer system sensor discovers computer systems running the Linux operating system.

Sensor name that is used in the GUI and logsLinuxComputerSystemSensor

PrerequisitesIf you discover Red Hat Enterprise Linux 7, or CentOS Linux 7 with the Linux computer system sensor, youmust install the ifconfig command on the targets. This command is included in the net-tools package.







Asynchronous and script-based discovery supportThe Linux computer system sensor supports asynchronous and script-based discovery.





LimitationsSome function that is provided by the Linux computer system sensor during a nonscript-based discoveryis not supported in an asynchronous or script-based discovery.


• Computer system templates and extensions• Deep Level 2 discovery• Discovery on Linux systems that are not x86 systems

The following attributes are not supported for the L2Interface model object:

• AutoNegotiation• Speed• Duplex

Model objects with associated attributesThe Linux computer system sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about computer systems running the Linuxoperating system.


Note: LinuxComputerSystemSensor does not discover CPU details of Linux on IBM Z.

core.LogicalContent

• Checksum• Configfile• Content


• ContentType• FixedPath• URI

sys.linux.LinuxUnitaryComputerSystem

• Architecture• BIOSDate• BIOSManufacturer• BIOSName• CPUCoresInstalled• CPUDiesInstalled• CPUSpeed• CPUType• Fqdn• Manufacturer• MemorySize• Model• Name• NumCPUs• SerialNumber• Signature• SystemId• TimeZone• Type• UUID• VirtualMachineState

net.L2Interface

• AutoNegotiation• Broadcast• Duplex• Encapsulation• HwAddress• InterfaceMTU• InterfaceName• Loopback• Mtu• Name• Promiscious• Speed• IANAInterfaceType

net.IpInterface



sys.CPU

• IndexOrder• CPUType• NumCPUs• CPUSpeed• CPUCoresInstalled• Virtual• CPUCore

sys.DNSResolveEntry




sys.linux.Linux

• BootTime• Charset• FQDN• KernelArchitecture• KernelModulesRawData• KernelVersion• Locale• Name• OSConfidence• OSMode• OSName• OSVersion• OsId• VirtualMemorySize• WordSize

sys.PageSpace

• Name• PageSpacePriority• Size• Type


• Name


• Publisher• Release• SoftwareVersion

sys.zOS.LPARsys.zOS.ZSeriesComputerSystemsys.zOS.ZVMGuest

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





Typically, an account with non-root privilege can be used. However, some commands that TADDM usesduring the discovery process may require privilege escalation (typically done using the sudo command).



You can configure the Linux computer system sensor in the Discovery Management Console by setting thefollowing attributes:ignoreVMCPCommand=false

This property is used when the vmcp command fails, which might lead to over merges of multipleLinux systems.The default value of this property is false. If the value is set to true, the vmcp command is ignored.The true value can be used, for example, when you have Linux installed on LPAR. To change the valueto true, you must create a new sensor configuration in the Discovery Profiles tab. In the CreateConfiguration window, change the value of the property from false to true, and select the Enablethis configuration and disable selected configuration option.

Note: This property is ignored when thecom.ibm.cdb.discover.zlinux.ignoreVMCPCommand.enabled property is set to true. Formore information, see the description of this property in the “Configuring the collation.properties fileentries” on page 326 section of the Linux computer system sensor.

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

The sensor uses the control program vmcp command to discover a Linux virtual system running on a z/VMoperating system. For each Linux virtual system, specify the path for the vmcp command in thecollation.properties file.

com.collation.platform.os.unix.find.excludenfsmount=falseThe default value is false.This property is used when "LinuxComputerSystemTemplate" extension template is enabled tofind the Capture File. This property is used to specify whether to use "find" command to search anycapture file configured using LinuxComputerSystemTemplate in NFS mount points or not.


If this property is set to true, LinuxComputerSystem Sensor will find the specified file on local serveronly, otherwise it will find it in NFS mount points also.

com.collation.platform.os.command.ifconfig=This property specifies a path to a command that is used to configure network interfaces. Theexample of such command is ifconfig. However, you can provide any other command that has thesame function, for example the ip command. Network interfaces are required for the discovery to besuccessful.

com.collation.platform.os.command.CPUSpeed=cat /proc/cpuinfo | grep 'cpuMHz'|awk '{print $4}'| tail -1

This property specifies the command that is used to retrieve the value of the CPUSpeed attribute thatis expressed in MHz. The default value of this property is cat /proc/cpuinfo | grep 'cpuMHz'|awk '{print $4}'| tail -1.

com.ibm.cdb.discover.zlinux.ignoreVMCPCommand.enabled=falseThis property specifies whether the ignoreVMCPCommand attribute, or thecom.ibm.cdb.discover.zlinux.ignoreVMCPCommand property is used. If this property is set tofalse, the ignoreVMCPCommand attribute is used. If this property is set to true, thecom.ibm.cdb.discover.zlinux.ignoreVMCPCommand property is used, which enables allsensors to discover the VMID and MMS attributes of Linux on System z targets.The default value of this property is false.

Important: Use this property only when you have problems with signatures that change when youdiscover Linux on System z targets. If you decide to set this property to true, you must set it to thisvalue in all discovery profiles, where the ignoreVMCPCommand attribute is set. Similarly, if thisproperty is set to false, it must be set to this value in all discovery profiles.

For more information about the ignoreVMCPCommand attribute, see “Configuring the discoveryprofile” on page 326 section of the Linux computer system sensor.

com.ibm.cdb.discover.zlinux.ignoreVMCPCommand=falseThis property is used only when thecom.ibm.cdb.discover.zlinux.ignoreVMCPCommand.enabled property is set to true.This property is used in the same way as the ignoreVMCPCommand attribute, only it is relevant to allsensors that discover Linux on System z targets, not just LinuxComputerSystemSensor. It provides thevalue of the ignoreVMCPCommand attribute for all such sensors to prevent over merges that arecaused by a wrong value of the VMID attribute, or no value at all.The default value of this property is false.

Important: Use this property only when you have problems with signatures that change when youdiscover Linux on System z targets. If you decide to set this property to true, you must set it to thisvalue in all discovery profiles, where the ignoreVMCPCommand attribute is set to true. Similarly, ifthis property is set to false, it must be set to this value in all discovery profiles.

com.collation.discover.agent.command.vmcp.Linux.1.2.3.4={command path}This value specifies the path name of the vmcp command for different Linux virtual systems withdifferent IP addresses. For example, to specify the path of the vmcp command in the /sbin directory,on a Linux host with IP address 192.168.1.2, add the following entry to the collation.propertiesfile:

com.collation.discover.agent.command.vmcp.Linux.192.168.1.2=sudo /sbin/vmcp

com.collation.platform.os.command.crontabEntriesCommand.Linux=crontab -l -uThis property is used to discover crontab entries. You can specify this property as a scoped propertyby appending an IP address or a scope set name to the property. The following example uses anappended IP address:

com.collation.platform.os.command.crontabEntriesCommand.Linux.1.2.3.4=crontab -l -u


com.collation.platform.os.command.crontabEntriesUsers.Linux=rootThis property is used to discover crontab entries for a specified user, use a comma-separated list tospecify more than one user. You can specify this property as a scoped property by appending an IPaddress 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







com.collation.discover.agent.ignoreVirtualMAC=trueThis property specifies whether the discovery of hardware addresses for virtual interfaces on Linuxtargets is enabled. If you set this property to true, hardware addresses are discovered.The default value of this property is true.

Related reference“Troubleshooting the sensor” on page 329


This topic describes common problems that occur with the Linux computer system sensor and presentssolutions for those problems.

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

Host Signature error occurs on Red Hat Enterprise Linux 7 and CentOS Linux 7targetsProblem

When you discover target systems that run Red Hat Enterprise Linux 7, or CentOS Linux 7, thefollowing error occurs:

2016-03-31 15:46:31,759 DiscoverManager [DiscoverWorker-7] SessionSensor-9.1.146.78-[22] DEBUG session.SshSessionClient - Command [LC_ALL=en_US.UTF-8;LANG=en_US.UTF-8;export LANG LC_ALL;ifconfig -a] failed in session ssh2:/HostAuthcom.collation.platform.security.auth.HostAuth[taddmcfm][XX XXX]/[email protected]: exit status 127 (no stdout)

SolutionTo solve the problem, you must install the ifconfig command on the targets. This command isincluded in the net-tools package.

In TADDM 7.3.0.4, and later, you do not have to use the ifconfig command. You canchoose any other command that can manage network interfaces. You must specify its name and pathin the com.collation.platform.os.command.ifconfig property in thecollation.properties file. For details, see “Configuring the collation.properties file entries” onpage 326.

The sensor fails with a command failed to run errorProblem

The following message is displayed:

Error Message: CTJTD0431E: The following command failed to run or returns a blank value: sudo /sbin/vmcp q userid | awk 'print{3}'.

The command vmcp q userid has failed to run or returns a blank value on the target Linux virtualsystem running on a z/VM operating system.

SolutionThis problem is caused by one of the following conditions:

• An incorrect path for the vmcp command on the target Linux virtual system.• The vmcp tool is not installed on the target Linux virtual system.• The sudo command is not configured to run the vmcp command.• The system name is not configured on the z/VM system.

To solve this problem, complete the following steps:

• Verify that the correct path for the vmcp command is entered in the collation.properties file.For details, see “Configuring the collation.properties file entries” on page 326.

• Verify that the system name is configured on the z/VM system, the system name cannot be blank.• 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.


• Verify that the sudo command is available. To verify run the following command on the Linux guestwhere 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 virtualmachine, 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/VMoperating system, it is not necessary to run the vmcp command. You can use the externalizedcommand property (com.collation.discover.agent.command.vmcp.Linux=) in the collation.propertiesfile to set the host system value to a "dummy" value. You must be able to parse the externalizedcommand with the following command appended to it:

q userid | awk '{ print $3 }'

For example, you might use:

com.collation.discover.agent.command.vmcp.Linux.192.168.1.2=echo A B zVMHost

This produces the echo A B zVMHost q userid | awk '{print $3 }' which returns thezVMHost name. The host attribute for your virtual systems is set to "zVMHost" instead of the actualhost system name.

• You can disable the vmcp command by setting the ignoreVMCPCommand command to true. Forinstructions, see “Configuring the collation.properties file entries” on page 326.

z/VM guests can be duplicated after multiple discoveries of the same Linux virtualsystemProblem

Duplicates can occur if the command vmcp q userid returns a blank value on the target Linuxvirtual system running on a z/VM operating system.

SolutionYou must manually merge these duplicates.

Linux Computer System Sensor captured memory size is inaccurate.Problem

When discovering Linux computer systems, the memory size captured by the sensor does not matchwith the installed memory size.

SolutionThe solution is to enable dmidecode, as it gives the most accurate value of installed memory.

OpenVMS computer system sensorThe OpenVMS computer system sensor discovers computer systems running the OpenVMS operatingsystem.

Sensor name that is used in the GUI and logsOpenVmsComputerSystemSensor

PrerequisitesTo run a successful discovery with the OpenVMS computer system sensor, you must complete thefollowing prerequisite tasks:

• Grant the discovery user the following privileges:

– CMKRNL


– NETMBX– SYSLCK– TMPMBX– WORLD

• Set the PGFLQUOTA parameter to 327680.





• core.LogicalContent• sys.openvms.OpenVms• sys.openvms.OpenVmsUnitaryComputerSystem





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

Sensor fails without any errorsProblem

The OpenVMS computer system sensor fails during the discovery, but it does not report any error. Thediscovery status is done, as if the discovery was successful.

SolutionGrant the discovery user the SYSLCK privilege.

INSVIRMEM error displayed on Software Licenses tabProblem

The Software Licenses tab contains the following message:

?%LIB-F-INSVIRMEM, insufficient virtual memory

SolutionTo solve the problem, set the PGFLQUOTA parameter to 327680.


Solaris computer system sensorThe Solaris computer system sensor discovers computer systems that are running the Solaris operatingsystem.

If you want to discover the Solaris Virtualization systems, run the Sun Sparc Virtualizationsensor. For more information, see “Sun Sparc Virtualization sensor” on page 338.

Sensor name that is used in the GUI and logsSunSparcComputerSystemSensor




The sensor discovers the number of physical processors if one of the following commands are present onthe target system:

• psrinfo -p• 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 ispresent 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, thefollowing command must be available for the network interface on the target system:

kstat network_interface_name | grep promisc

The sensor does not discover the ZFS file systems.

If you want to discover Solaris operating system by running generic server sensor, you must havethe /usr/ucb/ps command on the Solaris server. To install the command, install one of the followingpackages on the Solaris targets:

• Solaris versions earlier than 10: install one, or both of the following packages:

– Solaris 32 bit: the SUNWscpu package– Solaris 64 bit: the SUNWscpux package

• Solaris 10: the SUNWscpu package• Solaris 11: the compatibility/ucb package




Asynchronous and script-based discovery supportThe Solaris computer system sensor supports asynchronous and script-based discovery.




For script-based discovery, the access list configuration is the same as for a nonscript-based discovery.

LimitationsSome function that is provided by the Solaris computer system sensor during a nonscript-based discoveryis not supported in an asynchronous or script-based discovery.


• Computer system templates and extensions• Deep Level 2 discovery• Zone discovery

The following attributes are not supported:

• L2Interface

– AutoNegotiation– Speed– Duplex

• ComputerSystem (global zone)

– Virtual– ChildSystem– VMID– CPUCoresInstalled– CPUDiesInstalled

• ComputerSystem (local zone)

– Virtual– HostSystem– VMID– CPUCoresInstalled– CPUDiesInstalled


Model objects with associated attributesThe Solaris computer system sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about computer systems running the Solarisoperating system.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.sys.sun.SunSPARCUnitaryComputerSystem

• Name• Type• SystemId• VirtualMachineState• Signature• Fqdn• Manufacturer• Model• MemorySize• BIOSDate• BIOSName• NumCPUs• CPUType• CPUSpeed• Architecture• Virtual• TimeZone• CPUDiesInstalled• CPUCoresInstalled• ChildSystem

sys.CPU

• IndexOrder• CPUType• NumCPUs• CPUSpeed• CPUCoresInstalled• Virtual• CPUCore

sys.sun.Solaris

• Fqdn• Name• OSName• OSVersion• BootTime• PatchesInstalledRawData• KernelArchitecture


• KernelVersion• WordSize• Charset• OsId• KernelModulesRawData• OSMode• OSConfidence• VersionString

sys.DNSResolveEntry


core.LogicalContent



• Name• SoftwareVersion

net.L2Interface

• AutoNegotiation• Broadcast• Duplex• Encapsulation• HwAddress• InterfaceMTU• InterfaceName• Loopback• Mtu• Name• Promiscious• Speed• IANAInterfaceType

net.IpInterface



• AvailableSpace• Capacity• Group• MountPoint


• Owner• Permissions• Type

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





Typically, an account with non-root privilege can be used. However, some commands that TADDM usesduring the discovery process can require privilege escalation (typically done using sudo command).


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

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

com.collation.platform.os.command.crontabEntriesCommand.SunOS=crontab -lThis property is used to discover crontab entries. You can specify this property as a scoped propertyby appending an IP address or a scope set name to the property. The following example uses anappended IP address:

com.collation.platform.os.command.crontabEntriesCommand.SunOS.1.2.3.4=crontab -l

com.collation.platform.os.command.crontabEntriesUsers.SunOS=rootThis property is used to discover crontab entries for a specified user, use a comma-separated list tospecify more than one user. You can specify this property as a scoped property by appending an IPaddress 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

com.collation.discover.agent.useSolarisPfiles=falseThe default value is false.When set to true, this property causes the GenericServerSensor to use the ptree and pfilescommands on Solaris target systems to discover the list of IP sockets and ports that are associatedwith the running processes. The property replaces the use of lsof which might not be available in aSolaris environment.

com.collation.discover.agent.path.SunOS.prtdiag=/sbin/prtdiagThe default value is /sbin/prtdiag.This property is used to specify all the valid paths from where "prtdiag" can be executed on aSolaris server.This property is useful when you have multiple Solaris servers in your environment and differentservers have different paths from where prtdiag command can be executed. In such scenarios youcan add all the known valid paths using this property separated by colon (:).For example: com.collation.discover.agent.path.SunOS.prtdiag=/usr/sbin/prtdiag:/sbin/prtdiag:/sbin/sparcv9/prtdiag


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


The TADDM discovery user does not have authority to run the ps command with the full command-line arguments required to start the sensor.

SolutionComplete one of the following tasks:

• Set the sticky bit for the ps command, by using the following command:

chmod u+s /usr/ucb/ps

Note: The sticky bit might be overwritten by the operating system if a patch is applied that updatesthe ps command.

• Configure the ps command to run with sudo access for the TADDM discovery user by completingthe 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 -oruser,pid,ppid,comm

– com.collation.platform.os.command.psUsers.SunOS=sudo /usr/ucb/ps auxw2. Ensure that sudo access was granted to the TADDM discovery user by running the following

command on the target system:

sudo ps

Discovery fails during a discovery through IBM Tivoli MonitoringProblem

During a discovery through IBM Tivoli Monitoring, the discovery fails because of a problem withrunning the command cd $HOME;LANG=C zonecfg -z s8-zone info.

SolutionIn the collation.properties file, add the |.*zonecfg.* pattern to the end of the property:

com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*zonecfg.*

A local zone is discovered without an IP addressProblem

After discovery of a global zone, a local zone is discovered without an IP address.Solution

For some local zones that use an exclusive Ethernet adapter, a zone IP address cannot be determinedfrom the global zone level. You must run a direct discovery of such zone to obtain full informationabout it.

To obtain a local zone IP configuration manually, run the following command from the global zonelevel

zlogin <zonename> ifconfig -a inet


Note: If you are unable to get the zone IP address and getting the following exception:

com.collation.platform.session.SessionCommandFailedException:CTJTP1135E The following text is the exit status: 1.atcom.collation.platform.session.SshSessionClient.executeCommand1(SshSessionClient.java:538)

You can add a collation to obtain a local zone IP with sudo privilege in the zlogin command:

com.collation.platform.os.command.ifconfig="sudo ifconfig"orcom.collation.platform.os.command.ifconfig.SunOS="sudoifconfig"

zlogin command:

zlogin <zonename> sudo ifconfig -a inet

When you run the generic server sensor to discover Solaris targets, CTJTD0317Eand CTJTP1135E errors occurProblem

When you run the generic server sensor to discover Solaris operating system targets, the followingerror and exception occur in Discovery Management Console:

CTJTD0317E An error occurred. CTJTP1135E The following text is the exit status: 1

SolutionThe error indicates that the /usr/ucb/ps command is not installed on the Solaris server. To solve theproblem, install one of the following packages on your Solaris targets:

• Solaris versions earlier than 10: install one, or both of the following packages:

– Solaris 32 bit: the SUNWscpu package– Solaris 64 bit: the SUNWscpux package

• Solaris 10: the SUNWscpu package• Solaris 11: the compatibility/ucb package

Sun Sparc Virtualization sensorThe Sun Sparc Virtualization sensor discovers both types of Solaris Virtualization: Zones and LogicalDomains on a Solaris operating system.

Sensor name that is used in the GUI and logsSunSparcVirtualizationSensor

Sun Sparc Virtualization sensor discovery scopeThe sensor discovers whether the guest domains are active, and then retrieves all information aboutthe guest domains.The sensor also discovers whether the non-global zones are running, and then retrieves allinformation about the non-global zones.

Sun Sparc Virtualization sensor dependencyThe sensor depends on the Solaris computer system sensor, which runs just before the Sun SparcVirtualization sensor.The Solaris computer system sensor discovers the Solaris system with detailed information andpasses the SunSPARCUnitaryComputerSystem object to the Sun Sparc Virtualization sensor.For this SunSPARCUnitaryComputerSystem object, the Sun Sparc Virtualization sensor:


• discovers all available guest domains and non-global zones, and• for each of these creates the shallow SunSPARCUnitaryComputerSystem object.

The Sun Sparc Virtualization sensor can be run on Solaris systems that are of virtualization type:

Table 24. Solaris virtualization type discovery

Solaris Virtualization Type Discovers

Global zone Global zones and non-global zones

Non-Global zone* Non-global zone

Control Domain Control Domain (with name primary) and guestdomains

Guest Domain* Guest domain

Note: *To retrieve operating system details for the 'non-global zones' and 'guest domains', you must addthe IP address of the zones and domains to the discovery scope and rerun the Solaris computer systemsensor.

Model objects with associated attributesThe Sun Sparc Virtualization sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about computer systems running the Solarisoperating system with the available zones and logical domains.

The sensor creates the following model objects for the discovered zones and logical domains. Theattributes that are associated with each model object are shown below the model object name.For logical domainssys.sun.SunSPARCUnitaryComputerSystem

SystemIdTypeFunctionsPrimaryMACAddressMemorySizeNumCPUs

For non-global zonessys.sun.SunSPARCUnitaryComputerSystem

VirtualTypeVMIDFunctionsSystemIdDevicesConfigContentsFqdnHostSystemIsVMIDanLPARIpInterfaces

sys.FunctionName

• For logical domains: 'Guest domain' or 'Control domain'


• For zones: 'Zone'

• When IpInterfaceSensor agent runs: 'Router'

net.IpInterfaceIpAddress

Sun Fire SysControl sensorThe Sun Fire SysControl (SC) sensor discovers domains that are configured on Sun Fire systems.

The following information is obtained from the system controller on the Sun Fire system:

• Remote configuration administration operations• Board assignments and board status• Current usage statistics for Capacity on Demand (COD) resources• System board devices and resource usage information• System controller (SC) failover status or role• Platform type, board available component list, the domain state for each domain, and Capacity on

Demand (COD) information

Sensor name that is used in the GUI and logsSysControlSensor

Security issuesThe TADDM service account must have platform administrator privileges, which means that the account isa member of the UNIX group platadmn. Any user who is a member of the platadmn group has privileges torun the following System Management Services (SMS) commands:

• rcfgadm• showboards• showcodusage• showdevices• showfailover• showplatform

Model objects with associated attributesThe Sun Fire SysControl (SC) sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about domains that are configured on Sun Firesystems in your IT environment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.phys.physpkg.Board

• DisplayName• Name• PhysicalPackage• RelativePosition

sys.sun.DynamicSystemDomain

• Board• DisplayName


• Fqdn• HostSystem• IsVMIDanLPAR• Model• Name• NumCPUs• SerialNumber• Type• Virtual

sys.sun.SunFireComputerSystem

• ChildSystem• Devices• DisplayName• Manufacturer• Model• Name• SerialNumber• Type




1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password), that TADDM must use for either SSH key-


An account with platform administrator privileges must be used.


The sensor uses the following entries in the collation.properties file:com.collation.discover.agent.path.SunOS

This value specifies the path configuration for running commands.

The following commands are the System Management Services (SMS) commands that run:

• rcfgadm• showboards• showcodusage• showdevices• showfailover• showplatform


If the commands are in the opt/SUNWSMS/bin directory, for example, enter the following commandon one line:

com.collation.discover.agent.path.SunOS=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/sbin:/sbin:/opt/SUNWSMS/bin

com.collation.discover.agent.SysControlAgent.timeout=1200000This value specifies the time interval in milliseconds to allow the command to run.

Troubleshooting the sensorThis topic describes common problems that occur with the Sun Fire SysControl (SC) sensor and presentssolutions for those problems.

Sensor fails with a timeout errorProblem

During a discovery, the sensor fails with a timeout error.Solution

In the etc/collation.properties file, add the following property, where value is the number ofmilliseconds allowed for the sensor to run:

com.collation.discover.agent.SyscontrolAgent.timeout=1200000

Increase the value, until the sensor no longer fails with a timeout error.

The sensor fails with a getModelObject errorProblem

The following message is displayed:Error Message: CTJTD3021E: The sensor fails in a remote server: discoverSystemController: getModelObject failure

SolutionIn the etc/collation.properties file, add the path configuration for command execution (forexample, /opt/SUNWSMS/bin):

com.collation.discover.agent.path.SunOS=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/sbin:/sbin:/opt/SUNWSMS/bin

Tru64 computer system sensorThe Tru64 computer system sensor discovers computer systems running the Tru64 UNIX operatingsystem.

Sensor name that is used in the GUI and logsTru64ComputerSystemSensor

PrerequisitesThe sensor requires the following software:

• sudo command tool• lsof diagnostic tool

Install both tools in the same path as defined in the access list for accessing the Tru64 UNIX computersystem. This installation must be done on each Tru64 UNIX computer system to be discovered. The mosttested versions are sudo-1.6.8p9 and lsof-4.78, however, other versions are likely to work, except inthe case where the specific package does not support Tru64 UNIX. To get sudo-1.6.8p9 andlsof-4.78, go to the following Web sites:


• For sudo-1.6.8p9: http://www.gratisoft.us/sudo/download.html• For lsof-4.78: http://freecode.com/projects/lsof/?branch%20id=6029&release%20id=19567

Refer to the distributor Web sites or software readme files for a list of restrictions, such as the addition orremoval of support for a platform or function. If a particular package has restrictions, TADDM is affectedby those restrictions.





• core.LogicalContent• sys.ComputerSystem• sys.tru64.Tru64


Configuring non-root user to run the sensorYou must add the users credentials for non-root users.

Edit the /etc/sudoers file on the Tru64 UNIX computer system and add the following line, where non-rootuser is the user that runs the command:

<non-rootuser> ANY = NOPASSWD: /sbin/hwmgr

The /etc/sudoers must reside on the Tru64 UNIX computer system that is being discovered.

For example, to enable the user taddmusr to run the command on any Tru64 UNIX computer system,enter the following line:

taddmusr ANY = NOPASSWD: /sbin/hwmgr

For example, to enable the user taddmusr to run the /sbin/hwmgr command on a specific target systemnamed 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.





http://www.gratisoft.us/sudo/download.html

http://freecode.com/projects/lsof/?branch%20id=6029&release%20id=19567

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 Tru64computer system sensor carrying out the discovery can require privilege escalation. Typically, thisescalation is done by setting the file access permissions using the sudo command.


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

Storage error messages displayedProblem

Storage error messages.Solution

In this case, the Tru64 UNIX system issues a message with an Other IP Device status. Check thelocations and permissions on the dependencies and run the discovery again.

VMware ESX computer system sensorThe VMware ESX computer system sensor discovers VMware ESX servers.

Sensor name that is used in the GUI and logsVmwareComputerSystemSensor

Elements discovered by the sensorDiscovering the VMware ESX server (host machine) runs as it does for any other operating system. Themost important issues that impact discovery is connectivity and authentication. If the account configuredin the TADDM access list can connect to the VMware ESX server target, the discovery is successful.

Discoveries are launched using commands run over SSH.

Discovering the Virtual Machines (guest machines) actually discovers two instances of a VM, a physicalinstance and a virtual instance. After discovery, TADDM merges these two instances. The result is a singleinstance with all the attributes of a physical machine, but with the indication that it is virtual. In the XMLoutput of the database, this output is represented by an attribute such as:

<virtual>true</virtual>

In the Discovery Management Console, a VM (virtual machine) is represented by a computer system iconthat is blue and transparent.

The physical instance is discovered by the normal TADDM sensor for the particular guest operatingsystem, such as Linux. It is discovered just like a physical machine, which includes finding typical devicesand attributes. No special TADDM sensors are required to discover these virtual machines any differentlythan the physical machines they emulate.

The virtual instance is discovered by the VMware ESX sensor. It primarily uses configuration files (.vmx)and commands on the VMware ESX server to discover a shallow instance with data that can be describedas the following:

• Attribute data required to match naming rules and create a valid stand-alone VM instance• Certain basic information that the VMware ESX server provides through the vmware-cmd command.


• An attribute (primaryMACAddress) that is used to reconcile the shallow virtual instance with anyphysical instance that can be discovered.

There are two user scenarios for a VM discovery:

• All-inclusive: When discovering a scope that includes the server and physical instances, everythingworks as expected.

The result is a virtual instance that shows up in the appropriate domain to match its domain name. Thisvirtual 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 setto true, and a VMID attribute that gets set to the one specified in the .vmx configuration file. As long asthe TADDM server has connectivity and authentication to the VM, this scenario does not present anyproblems.

• VM-only: When discovering a scope that contains only the VM, it shows up as a physical machine withtypical 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, theicon 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.

LimitationsVMware vCenter servers are not discovered by the VMware ESX computer system sensor. If you mustdiscover these servers, use the VMware Virtual Center server sensor.

All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configured tobe down. TADDM does not populate the net.IpNetwork attribute on the following types of IP interfaces:



For VMware ESX server version 2.5 (all releases), you can discover virtual systems only that are running.


• core.LogicalContent• net.IpInterface• net.L2Interface• process.CPUResourcePool• process.MemoryResourcePool• process.NetworkAdapterResourcePool• relation.AllocatedTo• relation.DonatedTo• sys.CPU• sys.darwin.Darwin• sys.darwin.DarwinUnitaryComputerSystem• sys.dos.Dos• sys.dos.DosUnitaryComputerSystem


• sys.DNSResolveEntry• sys.FileSystem• sys.freebsd.FreeBSD• sys.freebsd.FreeBSDUnitaryComputerSystem• sys.linux.Linux• sys.linux.LinuxUnitaryComputerSystem• sys.Memory• sys.netware.Netware• sys.netware.NetwareUnitaryComputerSystem• sys.OperatingSystem• sys.sun.Solaris• sys.sun.SunSPARCUnitaryComputerSystem• sys.UnitaryComputerSystem• sys.vmware.VmwareESX• sys.vmware.VmwareUnitaryComputerSystem• sys.windows.WindowsComputerSystem• sys.windows.WindowsOperatingSystem


Configuring the discovery profileBy default, the VMware ESX computer system sensor is enabled for a Level 2 or Level 3 discovery. Thesensor discovers only guest systems that are running. To discovery all guests, create a Level 2 or Level 3discovery profile for the VMware ESX computer system sensor, and customize the sensor settings.



profile list, select Level 2 Discovery, or Level 3 Discovery, and click OK.4. On the Sensor Configuration tab, select the VmwareComputerSystemSensor sensor.5. In the Create Configuration window, type the name and description for your configuration, and select

the Enable Configuration check box.6. In the Configuration section of the Create Configuration window, click discoverNonRunningGuests.

Then double-click the Value field in the row, and type true.7. Click OK to return to the Discovery Profiles window.8. In the Discovery Profiles window, click Save.







com.collation.platform.os.command.osVersion.Vmware=/usr/bin/vmware –vThe default value is /usr/bin/vmware –v.

The command used to determine the version of VMware.

com.collation.platform.os.command.vmwareCmd=/usr/bin/vmware-cmdThe default value is /usr/bin/vmware-cmd.

The command used to perform operations on the virtual machine.

Troubleshooting the sensorThis topic describes common problems that occur with the VMware ESX computer system sensor andpresents solutions for those problems.

Duplicate VMs are createdProblem

After discovery, certain VMs seem to have duplicates.Solution

TADDM discovers two instances of a VM, one physical and one virtual. If they cannot be reconciled tothe same specific machine, two instances can exist in the database with similar attributes. These arenot duplicates, but two separately discovered instances of the same VM.This distinction is key to troubleshooting the problem, and there are several things to check, startingwith TADDM, moving into the VMware environment, and then finally troubleshooting the generalnetwork environment.Issues related to a pre-existing instance or database

The first item to check when troubleshooting a reconciliation problem is the database. If the VMhas made the transition to a new VM, the old VM might not be able to reconcile.The old instance can be deleted, preferably before restarting the discovery. If multiple runs arenecessary to try different solutions, remember to delete all instances of the existing VM inadvance.It can also help to delete the instance of the host ESX server. If it is feasible in the environment, itcan be helpful to drop and re-create the TADDM database between discovery runs. Then run anew discovery and see if the duplicates still exist.

<primaryMACAddress> attributeThe main reason that two instances of a VM cannot be reconciled is that they have different valuesin the <primaryMACAddress> attributes. To determine this value for each instance, it is necessaryto export the objects of type ComputerSystem from the TADDM database with the followingcommand run on the TADDM server:Non-Windows:

$COLLATION_HOME/sdk/bin/api.sh -u <username> -p <password> find --depth 1 ComputerSystem > <filename>.xml

Windows:

%COLLATION_HOME%\sdk\bin\api -u <username> -p <password> find --depth 1 ComputerSystem > <filename>.xml

An XML file that lists the first-level attributes for all instances of the ComputerSystem class isgenerated. Look for the short name of the duplicate instances and scroll down to the attributenamed <primaryMACAddress>.


If the value is different for the two instances, it is necessary to troubleshoot the MAC addressassignments in the configuration file on the server, on the VM itself, or both.

VM configurationIf a VM is configured in NAT or 'host only' mode, the VMwareESX sensor discovers the virtualinstance, but the physical instance is not discovered.

VM configuration files on the ESX host serverThe TADDM VMwareESX sensor gathers information from configuration files for each VM to bediscovered. 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 bythe .vmx extension.

These files are in XML format and are not case-sensitive. View the information in the configurationfile for the VM that has duplicate instances.

Validate the information for each interface to ensure that the MAC address for each linecorresponds 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 discoveryagain.

Configuration on the VM itselfOn 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. Youcan also verify that each interface is working by pinging the associated IP address. Try thediscovery again.

Recent changes in a VM or movement from one ESX server to anotherIf a VM has been migrated from one ESX server to another, it is possible that the configuration filewas 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 isgoing 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 beendeleted.The ESX server where the VM originated can also be specified as a target in a scope to see if theVM discovers correctly on that ESX server. If there are lines that have been deleted or modifiedduring migration, add or correct them and run the discovery again.

Name resolutionIf the VM cannot resolve to a single machine on the network, it can end up in TADDM as twoseparate 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 singleinstance.This is typically caused by a mismatch between hosts files, DNS, NIS, or any other nameresolution service.


The remedy is to test the name resolution by the machine short name a few times from the VMitself, the ESX server, and the TADDM server. All the responses must match. If they return differentresponses, modify the name service or hosts files until the results are consistent. Try thediscovery again.

General network connectivity & routingThere are global networking factors to consider in troubleshooting TADDM discoveries. As itrelates to VMware discoveries, a firewall or other networking consideration such as SSH mightpartially 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 labelunder the Physical Infrastructure: Overview > Systems Tier > Virtual Systems > VMware ESXThe VM itself appears only as an object under the heading of Other Ip Device or Other ComputerSystem.In the case where only the VM is discovered correctly by the OS sensor, it is displayed as theappropriate type of Computer System. The virtual instance is not displayed, and the ESX servermight not be displayed either.Correct the routing and firewall configuration until the TADDM server can ping and SSH to the ESXserver and directly to each of the VMs, then try the discovery again.

Duplicate VMware ESX servers are createdProblem

VMware ESX servers (Version 2.5 (all releases)) seem to be duplicated. This problem occurs when asequential discovery is run by using the VMware ESX computer system sensor followed by theVMware Virtual Center server sensor.

SolutionYou must manually merge duplicated VMware ESX servers.

The TADDM User's Guide contains information about using the Data Management Portal, includinginformation about discovery tasks, and how to manually merge discovered configuration items.

VMware ESXi computer system sensorThe VMware ESXi computer system sensor discovers VMware ESXi servers.

The VMware ESXi computer system sensor discovers VMware ESX servers, which support VMware API.

Sensor uses VMware API for discovery. VMware API is available on all ESXi servers and on ESX 3.x, ESX4.x versions. Sensor is not using ssh console.

Sensor name that is used in the GUI and logsVmwareESXiComputerSystemSensor

Elements discovered by the sensorFor Virtual Machines and for ESX server, the sensor discovers the same data as VirtualCenter sensor. Itcannot discover objects, which are higher in configuration tree than ESX, for example Clusters,Datacenters. Datastores are discovered with very limited data, with name only.

ESX Serial number can be discovered in two ways, either via VMware API like all other data or via CIM API.

PrerequisitesVMware API must be present and enabled on ESX server.

Security issuesTo discover the ESX server, you must set read-only permissions for the TADDM service account.


Connection to servers with SSLThe VMware ESXi computer system sensor can connect to servers with SSL in two modes - the defaultmode and a new mode.The default mode

The default mode does not fully verify the certificate of a server. This mode allows connection even ifthe certificate is self-signed, expired or with an invalid host name. It rejects connection when otherproblems are found, like certificate chaining error. The default mode can be used with the defaultVMware certificates.

The new modeThe new mode fully verifies the certificate of a server. You can enable this mode by setting thestrictCertificateCheck configuration property to true. When this mode is enabled, only validcertificates signed by trusted certificate authorities are accepted.

Importing self-signed certificates to TADDMBy setting the strictCertificateCheck property to true, you can connect with self-signedcertificates. You must first import such a certificate to TADDM. Though self-signed certificates aretrusted certificates, their validity is still verified.To import such certificates, complete the following steps:

1. Open the taddm/dist/osgi/plugins/com.ibm.cdb.discover.sys.vmware.vmwarecommon_* directory, where * is the versionnumber of the sensor.


java -cp lib/vmwarecommon.jar com.ibm.cdb.discover.sys.vmware.VmCertificateCollector ip:port

where ip is the IP address of the VMware ESXi computer system sensor host, and port is the SSLport of that host.


• net.IpInterface• net.L2Interface• process.CPUResourcePool• process.MemoryResourcePool• process.NetworkAdapterResourcePool• relation.AllocatedTo• relation.DonatedTo• sys.CPU• sys.vmware.VMWareDataStore• sys.unix.UnixFileSystem• sys.NFSFileSystem• sys.Memory• sys.vmware.VMWareVirtualSwitch• sys.vmware.VMWarePortGroup• sys.darwin.Darwin• sys.darwin.DarwinUnitaryComputerSystem• sys.dos.Dos• sys.dos.DosUnitaryComputerSystem


• sys.DNSResolveEntry• sys.FileSystem• sys.freebsd.FreeBSD• sys.freebsd.FreeBSDUnitaryComputerSystem• sys.linux.Linux• sys.linux.LinuxUnitaryComputerSystem• sys.Memory• sys.netware.Netware• sys.netware.NetwareUnitaryComputerSystem• sys.OperatingSystem• sys.sun.Solaris• sys.sun.SunSPARCUnitaryComputerSystem• sys.UnitaryComputerSystem• sys.vmware.VmwareESX• sys.vmware.VmwareUnitaryComputerSystem• sys.windows.WindowsComputerSystem• sys.windows.WindowsOperatingSystem


Configuring the discovery profileBy default, the VMware ESXi computer system sensor is enabled for a Level 2 or Level 3 discovery. Thesensor discovers only guest systems that are running and does not discover ESX serial number. To changethis behavior create new profile and customize sensor configuration.

Configuration items correspond to VirtualCenter sensor configuration.

The following properties can be set to true or false:ordinalESXviaVCserialDiscovery

It discovers a serial number by using VMware API. This is a standard way to discover the serialnumber, it is faster than by using CIM API, it requires fewer privileges, but is also more prone toerrors.The default value is false.

directESXserialDiscoveryIt discovers a serial number by using CIM API. This method always discovers the serial number, but isslower and the following requirements apply:

• The discovery user must have the Host > CIM > CIMInteraction privilege.• The connection between TADDM and the ESX server is required.

For more information, see also a technote at http://www-01.ibm.com/support/docview.wss?uid=swg21638454.

Important: If you run the ESX server on virtualized hardware like Cisco UCS, you must discover theserial number by using CIM API, not VMware API, because otherwise over merges might occur.

The default value is false.shallowVMdiscovery

It discovers limited data for Virtual Machine.The default value is false.




discoverNonRunningGuestsIt discovers not running Virtual Machines.The default value is false.

strictCertificateCheckIt forces the sensor to connect to ESX servers that are secured with valid, CA signed certificates.The default value is false.

enableVMDiscoveryIt enables the discovery of Virtual Machines.The default value is true.

Configuring the access listFind out what access detailed are required, depending on your configuration.

Sensor uses Computer System credentials to log into VMware API. VMware User must have read-onlypermissions for discovery.

Troubleshooting the sensorSome problems might occur with theVMware ESXi computer system sensor. Find out how to solve thecommon problems.

Ping sensor cannot find reachable ipProblem

The ping sensor scans port 22 and 135. If these ports are not found, the discovery ends. ESXi sensorby default has these ports blocked.

SolutionTo enable the discovery, configure the ports to scan in the collation.properties file in thecom.collation.pingagent.ports property or add an exception on ESX firewall.

ESXi sensor does not startProblem

To enable the ESXi sensor start after Port sensor, Port sensor must discover ESXi ports. If the portsare configured differently, the ESXi sensor does not start.

SolutionDefault port values are 902, 80, 443. If ESXi sensor has different ports configured, reconfigure Portsensor.

Windows computer system sensorThe Windows computer system sensor discovers computer systems running Microsoft Windows operatingsystems.

Sensor name that is used in the GUI and logsWindowsComputerSystemSensor

PrerequisitesFor discovery using a gateway, the gateway must be accessible through SSH.

To discover Windows systems without using a gateway:

• The Windows systems must be accessible through SSH.• Microsoft .NET Framework must be installed on Windows target systems. For more information, see theConfiguring for discovery of Windows systems topic in the TADDM Administrator's Guide.


• Windows Scripting Host (WSH) 5.6 or higher must be installed on the target Windows systems. WindowsScripting Host is installed with Internet Explorer 6 Service Pack 1 or higher.

• Windows Server 2016Due to a Powershell 5 issue, you must contact your IBM Support representative and request that aPowershell 5 eFix be applied, before attempting the discovery of a Windows Server 2016 without agateway. Once this has been done, discovery of the Windows 2016 server via direct SSH willfunction normally.

Limitations• If you provide user credentials without the administrator role, the Windows computer system sensor is

not able to collect the list of services and devices that are related to Windows Server 2003. In result,the related tables in Data Management Portal are empty.

• All computer system sensors and the SNMP MIB2 sensor ignore network interfaces that are configuredto be down. TADDM does not populate the net.IpNetwork attribute on the following types of IPinterfaces:

– loopback, for example, 127.0.0.1, 0:0:0:0:0:0:0:1– link-local, for example, 169.254.1.1, FE80:0:0:0:0:0:0:1– multicast, for example, 224.0.0.1, FF00:0:0:0:0:0:0:1– unspecified, for example, 0.0.0.0, 0:0:0:0:0:0:0:0




Discovery of CPU informationThe NumCPUs attribute value is set to the number of logical CPUs on the computer system. Ifhyperthreading is enabled on the Windows target system, the NumCPUs attribute also includes thehyperthreads. For example, on dual core system with hyperthreading enabled, the value of the NumCPUsattribute is 4. If hyperthreading is not enabled, the value of the NumCPUs attribute is 2.

Asynchronous and script-based discovery supportThe Windows computer system sensor supports asynchronous and script-based discovery.

Sensor configuration requirementsFor information about configuring for script-based discovery, see the Configuring for script-baseddiscovery topic in the TADDM Administrator's Guide.




LimitationsThe sensor requires powershell environment on target system for asynchronous and script-baseddiscovery. The powershell version must be 2 or higher.

Script-based discovery is supported for following target systems:

• Windows 7• Windows 8• Windows Server 2008• Windows Server 2012• Windows Server 2016 Standard Edition• Windows Server 2016 Datacentre Edition

• Windows Server 2019 Standard Edition

Model objects with associated attributesThe Windows computer system sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about computer systems running the Windowsoperating system.



dev.MediaAccessDevice

• Name• Type• Status

sys.DNSResolveEntry


net.L2Interface

• Encapsulation• HwAddress• InterfaceName• Loopback• Name• Index• IANAInterfaceType• InterfaceSpeed• Speed

net.IpInterface

• IpAddress• L2Interface


• IpNetwork

sys.CPU

• IndexOrder• NumCPUs• CPUType• CPUSpeed• CPUCoresInstalled• Virtual• CPUCore

sys.FileSystem



• Name• SoftwareVersion• Publisher

sys.windows.WindowsService

• ServiceName• CanBePaused• CanBeStopped• DesktopInteract• ErrorControl• OperatingState• Started• StartMode• Account• PathName• ExitCode• ServiceSpecificCode• ServiceType• Description• Name• SoftwareVersion• ProcessId

sys.windows.WindowsComputerSystem

• UUID• Name


• Type• SystemId• SystemBoardUUID• VirtualMachineState• Signature• Fqdn• SerialNumber• Manufacturer• Model• MemorySize• NumCPUs• CPUType• CPUSpeed• Architecture• CPUDiesInstalled• CPUCoresInstalled

sys.windows.WindowsOperatingSystem

• Fqdn• Name• OSName• OSVersion• BootTime• KernelArchitecture• KernelVersion• Charset• Locale• OsId• OSConfidence• ServicePack• VersionString

Configuring the sensorBefore using the Windows computer system sensor, you must configure it.

Complete the following setup:

• Install all required software.• For discovery using a gateway, WMI must be enabled on all target Windows systems. WMI is enabled by

default.

By default, discovery using a gateway automatically installs the TADDM WMI Provider on all targetWindows systems during the discovery process.




1. For full discovery of Windows hosts and software, each Windows machine requires a service account inthe local admin group with WMI access to all WMI objects on that machine. This account can be a localaccount or a domain account.

The service account must be created on the Windows gateway and all target Windows computersystems.

2. Access list entries must be created for the Windows computer systems (gateway and the targetWindows systems).

When specifying a Windows domain user account for an access list entry, the domain name and username must be separated by a backslash (\) as shown in the following example: DOMAIN\username.

3. TADDM also supports SNMP-based discovery of Windows systems. To support SNMP-based discovery,complete the following steps:

a. Enable SNMP.b. Ensure that the SNMP MIB2 GET Community string has access permission for MIB2 System, IP,

Interfaces, Extended Interfaces, and Host Resources.

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

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

com.ibm.cdb.skipWindowsSoftware=false

Note: This property affects only script-based mode of the discovery.

This property specifies whether the installed software on the Windows operating system isdiscovered.The default value is false, which means that the software is discovered.If the amount of the discovered data is very large and it slows down the discovery process, set thisproperty to true to disable the discovery of this type of data.








Gateway-based or SSH-based discovery propertiescom.collation.AllowPrivateGateways=true

The default value is true.

This property specifies whether a Windows computer system can be discovered using SSH or IBMTivoli Monitoring connections without requiring an intermediate gateway. The default is to allow SSHor IBM Tivoli Monitoring connections to Windows systems. If the value is set to false, Windowstargets are only discovered if they are listed in the TADDM gateway list. If they are not included in thegateway list, the Windows session sensor fails with the CTJTP1100E error.

com.collation.PreferWindowsSshOverGateway=falseThe default value is false.

This property specifies whether to use SSH rather than gateway-based discovery if a Windowscomputer system supports SSH. Even if a Windows computer system supports SSH, the default valuefor this property indicates that gateway-based discovery is used. This property is ignored ifcom.collation.AllowPrivateGateways=false.

WMI-related propertiesTADDM 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 isrestarted, all WMI-dependent services that were running before the restart are also restarted.

com.collation.discover.agent.windows.useIpAsDomain=falseThe default value is false.This property specifies the format of credentials that is used to establish WMI session. By default,credentials in the user format are used.If you set this property to true, credentials in the IP/user format are used in addition to the defaultformat.This property is a scoped property, you can append the IP address or name of the scope to thisproperty. For example:

com.collation.discover.agent.windows.useIpAsDomain.9.100.100.200=falsecom.collation.discover.agent.windows.useIpAsDomain.scope_name1=false

com.collation.WmiAccessEnabled=trueThe default value is true, which indicates that TADDM attempts to establish the WMI session.This is a discovery profile property. You can configure it with the highest priority on the PlatformProperties tab of the Discovery Profiles pane in Discovery Management Console. You can also defineit for a specific scope set, or IP, in the collation.properties file.

com.collation.platform.os.WindowsOs.AutoDeploy=trueThe 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. Manualdeployment 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 truemight provide more reliable Windows discovery, but you must also consider the potential negative impactof the WMI service being temporarily stopped and restarted.


com.collation.RestartWmiOnAutoDeploy=falseRestart WMI if a WMI error occurs during automatic deployment of the TADDM WMI Provider.

com.collation.RestartWmiOnAutoDeploy.1.2.3.4=falseRestart WMI if a WMI error occurs during automatic deployment of the TADDM WMI Provider.

com.collation.RestartWmiOnFailure=false

Restart WMI if a WMI error occurs, except during automatic deployment.

com.collation.RestartWmiOnFailure.1.2.3.4=false

Restart WMI if a WMI error occurs, except during automatic deployment.

PowerShell-related properties

com.ibm.cdb.session.ps.urlPrefix=wsmanThe default value is wsman.This property specifies the value of the URLPrefix property of a WinRM listener on the discoveredWindows system. The value of this property and the URLPrefix property on the Windows targetsmust be the same.This is a scope-based property. You can override the global value for a specific scope set or IP in thecollation.properties file.

com.collation.PowerShellAccessEnabled=falseThe default value is false.This property specifies whether TADDM attempts to establish the PowerShell session. By default, thePowerShell access is disabled. If you want to enable the PowerShell session, set this property totrue.This is a discovery profile property. You can configure it with the highest priority on the PlatformProperties tab of the Discovery Profiles pane in Discovery Management Console. You can also defineit for a specific scope set, or IP, in the collation.properties file.

com.collation.PreferPowerShellOverWMI=trueThe default value is true.This property specifies whether to use the PowerShell or the WMI session, if both of them areenabled. By default, the PowerShell session is preferred.This is a scope-based property. You can override the global value for a specific scope set or IP in thecollation.properties file. For example:

com.collation.PreferPowerShellOverWMI.myScopeABC=falsecom.collation.PreferPowerShellOverWMI.10.100.27.8=true

com.collation.PowerShellPorts=5985,5986The default value is 5985,5986.This property specifies the PowerShell ports. By default, ports 5985 and 5986 are specified. ThePortSensor checks whether these ports are active. If the ports are active, the PowerShell session canbe established. If the ports are not active, the WMI session is used instead, unless you disabled it. Insuch case, error messages are displayed.This is a discovery profile property. You can configure it with the highest priority on the PlatformProperties tab of the Discovery Profiles pane in Discovery Management Console. You can also defineit for a specific scope set, or IP, in the collation.properties file.

com.ibm.cdb.session.ps.useSSL=falseThe default value is false.This property specifies whether the PowerShell script uses the SSL protocol to connect to the remotehost. By default, the SSL protocol is not used.


This is a scope-based property. You can override the global value for a specific scope set or IP in thecollation.properties file.

com.ibm.cdb.session.ps.allowDNS=true

Note: You can use this property only when the com.ibm.cdb.session.ps.useSSL property is setto true.

The default value is true.This property specifies whether the PowerShell script uses DNS on the gateway to resolve the IP ofthe remote host. By default, the usage of DNS is allowed.This is a scope-based property. You can override the global value for a specific scope set or IP in thecollation.properties file.

com.ibm.cdb.session.ps.fallbackToIP=true

Note: You can use this property only when the com.ibm.cdb.session.ps.useSSL andcom.ibm.cdb.session.ps.allowDNS properties are set to true.

The default value is true.This property specifies whether the PowerShell script falls back to IP when a secure session cannotbe established by using FQDN. By default, the PowerShell script falls back to IP.This is a scope-based property. You can override the global value for a specific scope set or IP in thecollation.properties file.

com.collation.PowerShellTimeoutFudge=10000The default value is 10000 (milliseconds).This property specifies the time after which SSH protocol times out, starting with the timeout of thePowerShell script. By default, when the PowerShell script times out, the SSH protocol times out10000 milliseconds later.

Configuring for a non-admin Windows discoveryYou can configure the sensor to run discoveries without providing user credentials with the administratorrole.

Depending on which type of session you enable, the following steps are required:WMI session

• “Creating a discovery user account” on page 361• “Setting up the WMI configuration” on page 361• “Copying the TaddmWmi files” on page 362• “Setting up the DCOM Access for ibmcol” on page 362

PowerShell session

• “Creating a discovery user account” on page 361• “Setting up the WMI configuration” on page 361• “Setting up the PowerShell configuration” on page 362

Both WMI and PowerShell sessions

• “Creating a discovery user account” on page 361• “Setting up the WMI configuration” on page 361• “Setting up the PowerShell configuration” on page 362• “Copying the TaddmWmi files” on page 362• “Setting up the DCOM Access for ibmcol” on page 362

See also the Configuring for discovery of Windows systems topic in the TADDM Administrator's Guide.


Creating a discovery user accountWhen you create an account, you are able to choose the right permissions and provide information that isneeded for a non-admin Windows discovery.

You can create a discovery user account on the stand-alone Windows server and on the Active Directorydomain server. Use either of the following instructions to complete this task.

Creating a discovery user account on the stand-alone Windows serverCreate a discovery user account on the stand-alone Windows server.

1. Open Computer Management Console by running the compmgmt.msc command.2. In the navigation tree, expand System Tools > Local Users and Groups > Users.3. From the Action menu, click New User.4. Provide the following information:

a) User name: ibmcolb) Full name: TADDM discovery userc) Description: TADDM discovery userd) Password

5. Clear the User must change password at next logon check box.6. Select the Password never expires check box.7. Click Create.8. To verify whether the new user is a standard user by default, right-click the user name, and then click

Properties. In the Properties window, go to the Member Of tab. If the user is a standard user,Administrators group is not on the list.

Creating a discovery user account on the Active Directory domain serverCreate a discovery user account on the Active Directory domain server.

1. Open Active Directory Users and Computers by running the dsa.msc command.2. In the navigation tree, select domain_name and then select the Users folder.3. Right click the menu and choose New > User.4. Provide the following information:

a) First name:ibmcolb) Logon name:ibmcol

5. Click Next and provide password.6. Clear the User must change password at next logon check box.7. Select the Password never expires check box.8. Click Create.9. To verify whether the new user is a standard user by default, right-click the user name, and then click

Properties. In the Properties window, go to the Member Of tab. If the user is a standard user,Administrators group is not on the list.

Setting up the WMI configurationWhen you set up the WMI configuration, you can add the user to the access list to enable permissions thatare required for the discovery.

1. In the navigation tree of the Computer Management Console, expand Services and Applications >WMI Control.

2. From the Action menu, click Properties.3. Click the Security tab, select Root namespace, and click Security.4. Add the ibmcol user to the list. The following permissions must be allowed:

a) Execute Methodsb) Enable Account


c) Remote Enable5. Click Advanced and choose the ibmcol user from the list6. Change the Apply to property to This namespace and subnamespaces.7. Click OK.

Note: For the Active Directory domain setup, this procedure must be repeated for each computer thatis a part of the domain. Microsoft does not provide any domain-wide WMI configuration tool.

Setting up the PowerShell configurationIf you enabled the PowerShell session, you must configure the target systems to enable the non-admindiscovery.

1. On the target system, run the following command:

Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI -Force

With the -Force option, you are not prompted to confirm this action.2. In the new window that is displayed, select the ibmcol user.

If the user is not on the list, click Add... and search for it.3. From the permissions list, select Read(Get,Enumerate,Subscribe) and Execute(Invoke) in the Allow

column.4. Click OK.

Copying the TaddmWmi filesThe files are used for agentless discovery. They are required to enable additional methods to be called viaWMI.

1. Copy the following TaddmWmi files to the C:\Windows\system32\wbem directory on a 32-bitsystem and to the C:\Windows\SysWOW64\wbem directory on a 64-bit system:

• TaddmWmi.pdb• TaddmWmi.exe• TaddmWmi.mof• TaddmWmi.dll

2. Compile and register TaddmWMI.dll by running the following commands:

• On the 32-bit Windows operating system:

%SystemRoot%\System32\wbem\mofcomp.exe %SystemRoot%\System32\wbem\TaddmWmi.mof %SystemRoot%\System32\regsvr32 /s %SystemRoot%\System32\wbem\TaddmWmi.dll

• On the 64-bit Windows operating system:

%SystemRoot%\SysWOW64\wbem\mofcomp.exe %SystemRoot%\SysWOW64\wbem\TaddmWmi.mof %SystemRoot%\SysWOW64\regsvr32 /s %SystemRoot%\SysWOW64\wbem\TaddmWmi.dll

Note: You can also deploy the WMI files automatically by running a standard administrator discovery.

Setting up the DCOM Access for ibmcolYou must set up the DCOM Access for the user to enable permissions that are required for the discovery.

To set up the DCOM Access for the user on the stand-alone Windows server or the Active Directorydomain server, use either of the following instructions.

Setting up the DCOM Access for ibmcol on the stand-alone Windows serverComplete the following steps to set up the DCOM Access for the user on the stand-alone Windows server.

1. Open the Component Services Administrative Tool by running the dcomcnfg command.2. In the navigation tree, expand Component Services > Computers > My Computer.


3. From the Action menu, click Properties, and go to the COM Security tab.4. In the Access Permissions section, click Edit Default.5. Add the ibmcol user to the list and ensure that it has the Local Access and Remote Access

permissions enabled, and click OK.6. In the Access Permissions section, click Edit Limits.7. If the button is grayed out, complete the following steps:

a) Open Local Security Policy by running the secpol.msc command.b) Expand Local Policies and click Security Options.c) Select the following policy: DCOM: Machine Access Restrictions in Security Descriptor

Definition Language (SDDL) syntax.d) Right-click the policy and choose Properties from the menu. Then, click Edit Security.

8. Add the ibmcol user to the list and ensure that the Local Access and Remote Accesspermissions are enabled, and click OK.

9. In the Launch and Activation Permissions section, click Edit Default.10. Add the ibmcol user to the list and ensure that it has the Local Launch and Remote Launch

permissions enabled, and click OK.11. In the Launch and Activation Permissions section, click Edit Limits.12. If the button is grayed out, complete the following steps:

a) Open Local Security Policy by running the secpol.msc command.b) Expand Local Policies and click Security Options.c) Select the following policy: DCOM: Machine Launch Restrictions in Security Descriptor

Definition Language (SDDL) syntax.d) Right-click the policy and choose Properties from the menu. Then, click Edit Security.

13. Add the ibmcol user to the list and ensure that the Local Launch, Remote Launch, LocalActivation, and Remote Activation permissions are enabled, and click OK.

14. Restart the Windows server.

Setting up the DCOM Access for ibmcol on the Active Directory domain serverComplete the following steps to set up the DCOM Access for the user on the Active Directory domainserver.

1. Open Group Policy Management by running the gpmc.msc command.2. Choose forest and domain and select a domain policy, for example Default Domain Policy.3. Click Action > Edit.4. Open Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security options.

5. Select the following policy: DCOM: Machine Access Restrictions in Security Descriptor DefinitionLanguage (SDDL) syntax.

6. Right-click the policy and choose Properties from the menu. Then, click Edit Security.7. Add the ibmcol user to the list and ensure that the Local Access and Remote Access permissions are

enabled, and click OK.8. Select the following policy: DCOM: Machine Launch Restrictions in Security Descriptor Definition

Language (SDDL) syntax.9. Right-click the policy and choose Properties from the menu. Then, click Edit Security.

10. Add the ibmcol user to the list and ensure that the Local Launch, Remote Launch, Local Activation,and Remote Activation permissions are enabled, and click OK.

11. Run the gpupdate command to refresh the policy settings.


Setting up the SC Manager access for ibmcolYou must set up the SC Manager Access to enable the non-admin window users to discover the window2016 and window 2019 servers in the network mode.

This section describes the tasks on how to set up the access on SC Manager for the user on the stand-alone windows server or the Active Directory domain server.

Note: This task is applicable for the latest versions of the window 2016 and window 2019.

1. Open the command prompt in the Administrator mode.2. Run the below command to get the user SID from the target system:

wmic useraccount where name="ibmcol" get name,sid

3. Make a note of the user SID from step 2, for example:S-1-5-21-3437249340-2515582971-2711699987-1011

4. Run the below command to get the current SDDL for the SC Manager:

sc sdshow scmanager > CurrentSDDL.txt

Note: Above command will save the current SDDL for the SC Manager to the CurrentSDDL.txt5. Make a note of the current SDDL from step 4, for example: D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)

(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)(A;;CC;;;S-1-15-3-1024-528118966-3876874398-709513571-1907873084-3598227634-3698730060-278077788-3990600205)S:(AU;FA;KA;;;WD)(AU;OII OFA;GA;;;WD)

Note: You can view CurrentSDDL.txt, that contain current SDDL, by running the below command:

CurrentSDDL.txt

6. Edit the below string to frame a new SDDL snippet using the SID that you noted in above step 3.

(A;;CCLCRPWPRC;;;<SID in step 3>)

Note: Add SID in above string to create a new SDDL snippet, for example:(A;;CCLCRPWPRC;;;S-1-5-21-3437249340-2515582971-2711699987-1011)

7. Add the above new SDDL snippet before word "S:" in the original SDDL that you noted in step 5, forexample: D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)(A;; CC;;;S-1-15-3-1024-528118966-3876874398-709513571-1907873084-3598227634-3698730060-278077788-3990600205)(A;;CCLCRPWPRC;;;S-1-5-21-3437249340-2515582971-2711699987-1011)S:(AU;FA;KA;;;WD)(AU;OII OFA;GA;;;WD)

8. Add string "sc sdset scmanager" in the updated SDDL that is created at step 7 in the beginning and runas command, for example:

sc sdset scmanager D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)(A;; CC;;;S-1-15-3-1024-528118966-3876874398-709513571-1907873084-359 8227634-3698730060-278077788-3990600205)(A;;CCLCRPWPRC;;;S-1-5-21-3437249340-2515582971-2711699987-1011)S:(AU;FA;KA;;;WD)(AU;OII OFA;GA;;;WD)

Once the command in step 8 runs successfully, the below message will be displayed in the commandprompt:

[SC] SetServiceObjectSecurity SUCCESS

Automatic configurationThe steps setting up the WMI configuration, copying the TaddmWmi files, and setting up the DCOM Accessfor ibmcol can be replaced with the automatic configuration. If you use TADDM 7.3.0.3, or later, thesetting up the PowerShell configuration step can be also automated.

1. Copy the following files to the target system.


a) The following script files can be found in the $COLLATION_HOME/dist/support/bin directory.

• copyFiles.ps1• dcomConfiguration.ps1• nonadmin.properties

• psSessionConfiguration.ps1• scriptsRunner.bat

• scriptsRunner.ps1• wmiConfiguration.ps1

• wrmConfiguration.ps1b) The following TaddmTool Provider files can be found in $COLLATION_HOME/dist/lib/ms/gateway directory.

• TaddmWmi.pdb• TaddmWmi.exe• TaddmWmi.mof• TaddmWmi.dll

2. Configure the nonadmin.properties file by updating the nonadmin.user, andnonadmin.files.path properties:

nonadmin.user=usernonadmin.wmi.namespace=rootnonadmin.files.path=pathnonadmin.permissions=Enable,MethodExecute,RemoteAccess

The user value is the user that you want to use for non-admin discovery. If you specify the local user,you need to add only the user name. Otherwise, provide also the domain name, for example, domain\user. The path value is the path to the directory where you copied files in step 1. Do not modify thevalues of the remaining properties.

3. By using command prompt, run the scriptsRunner.bat file.

In TADDM 7.3.0.3, and later, the scriptsRunner.bat file requires the -wmi, or the -psparameters, or both.

• scriptsRunner.bat -wmi - executes the steps setting up the WMI configuration, copying theTaddmWmi files, and setting up the DCOM Access.

• scriptsRunner.bat -ps - executes the steps setting up the WMI configuration, and setting upthe PowerShell configuration.

• scriptsRunner.bat -wmi -ps - executes the steps of both -wmi, and -ps parameters.

In TADDM 7.3.0.4, and later, you must use the set command and at least one of thefollowing parameters:

• scriptsRunner.bat set -wmi - executes the steps setting up the WMI configuration, copyingthe TaddmWmi files, and setting up the DCOM Access.

• scriptsRunner.bat set -ps - executes the steps setting up the WMI configuration, and settingup the PowerShell configuration.

• scriptsRunner.bat set -wmi -ps - executes the steps of both -wmi, and -ps parameters.4. Restart the system.

If you decide not to run non-admin discoveries any longer, you can revert to the originalconfiguration. Run the scriptsRunner.bat with one of the following options:

• scriptsRunner.bat revert -wmi• scriptsRunner.bat revert -ps


• scriptsRunner.bat revert -wmi -ps

Restart the system.

Related reference“Configuring for a non-admin IIS discovery” on page 116You can configure the Microsoft IIS Web server sensor to run non-admin discovery of IIS servers. Suchdiscovery does not require a user with administrator rights. In this mode, the User Account Control (UAC)option can be enabled.

TroubleshootingSome errors might occur while you run a non-admin Windows discovery. You can find here thedescriptions of the most common errors and see how to fix them.

The session sensor ends with the CTJTP1163E errorProblem

The following error might occur if the DCOM configuration and WMI configuration for the non-adminuser is not correct:

CTJTP1163E The following WMI session cannot be established (WMI: SELECT BuildVersion FROM Win32_WMISetting failed: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED));

SolutionFollow the instructions from the following sections: “Setting up the WMI configuration” on page 361and “Setting up the DCOM Access for ibmcol” on page 362.

The session sensor ends with the CTJTP1161E errorProblem

The following error might occur if the non-admin user is configured correctly, but the TADDM WMI fileswere not deployed:

CTJTP1161E The application cannot establish the following WMI session: SessionClientException: InstallProvider failed: could not copy files to remote host: System.Exception: WNetAddConnection2: Access is denied.

SolutionFollow the instruction from the following section: “Copying the TaddmWmi files” on page 362.

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

Problem with WMIProblem

Windows Management Instrumentation (WMI) fails on the system that is to be discovered, whichcauses discovery to fail.

SolutionRestarting WMI might correct the problem. Use the following commands to restart WMI:

net stop winmgmtnet start winmgmt

If restarting WMI does not correct the problem, use the following Microsoft utilities to troubleshootWMI problems. These utilities are available at https://technet.microsoft.com/en-us/scriptcenter/dd772288.aspx.


https://technet.microsoft.com/en-us/scriptcenter/dd772288.aspx

https://technet.microsoft.com/en-us/scriptcenter/dd772288.aspx

WMIDiagFollow the instructions to install and run the utility, and verify that WMI is working correctly.

ScriptomaticThe Scriptomatic utility can be used to generate WMI queries that are similar to those used byTADDM. The following WMI classes are some that TADDM queries:

• Win32_Process• Win32_OperatingSystem• Win32_WMISetting• Win32_ComputerSystem

Verify that these classes can be queried using the Scriptomatic utility locally on the target systemand remotely from the gateway.

Problem with deployment of WMI providerProblem

For discovery of Windows systems, TADDM deploys a WMI provider to each target system to enableagentless discovery. Sometimes, problems occur with this deployment.

SolutionThe 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 functionalityTaddmWmi.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 commandTaddmWmi.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 systemthat is in the discovery scope (it uses either the Admin$ or C$ directory to do this): %SystemRoot%\System32\wbem

2. Runs the following commands on each target system:On 32-bit Windows operating systems:

%SystemRoot%\System32\wbem\mofcomp.exe %SystemRoot%\System32\wbem\TaddmWmi.mof%SystemRoot%\System32\regsvr32 /s %SystemRoot%\System32\wbem\TaddmWmi.dll

On 64-bit Windows operating systems:

%SystemRoot%\SysWOW64\wbem\mofcomp.exe %SystemRoot%\SysWOW64\wbem\TaddmWmi.mof%SystemRoot%\SysWOW64\regsvr32 /s %SystemRoot%\SysWOW64\wbem\TaddmWmi.dll

To troubleshoot WMI or access-related problems, you can run the TADDM WMI installation providermanually. 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 gatewaydirectory. If fixes have been applied to the TADDM server, more than one gateway directory mightbe present. The identifier string can be found in the DiscoveryManager.log file after thefollowing item: DTADDM_ID=


2. set TADDM_USERNAME=domain\userid3. set TADDM_PASSWORD=password_for_userid4. set TADDM_INTERACTIVE=15. TaddmTool InstallProvider -AutoDeploy @ipaddress, where ipaddress is the IP

address of the target system

WMI access denied errorsProblem

You have WMI access denied errors.Solution

Refer to Appendix F of the Deployment Guide Series: IBM Tivoli Change and Configuration ManagementDatabase Configuration Discovery and Tracking v1.1, an IBM Redbooks® publication, at http://www.redbooks.ibm.com/abstracts/SG247264.html.

WMI process creation errorsProblem

WMI process creation fails with an access error during provider installation. There might be a problemwith the Windows Replace a Process Level Token privilege not being granted to the requiredaccounts.

Solution

• This privilege should be granted to the LOCAL SERVICE and NETWORK SERVICE accounts. To verifythis, complete the following steps:

1. Log onto the target machine using the console or the Terminal Server Client.2. Click Start.3. Select Run.4. Enter gpedit.msc to start the Group Policy editor.5. Descend down the tree of privileges under Local Computer Policy > Computer Configuration >

Windows Settings > Security Settings > Local Policies > User Rights Assignment.• If you cannot change the accounts assigned to the Replace a Process Level Token privilege, try to

add the discovery account to a group that has that privilege.

Check to see if the Tivoli_Admin_Privileges group has the privilege. If it does, make the discoveryaccount a member of that group.

The specified network name is no longer availableProblem

If this error occurs, or if there is a problem copying files to the target during provider installation, theremight be a problem connecting to the SMB (file sharing) service on the target machine.

Solution


1. Check to see if an SMB port is listening.

• Windows 2003 will listen on port 445.• Windows 2000 may listen on either 445 or 139.

2. On the gateway, check to see if a connection is allowed or refused by opening a command windowand running the following command:

telnet <target machine name> 445

3. If it is refused, repeat step b using port 139. If both fail, you have one of the following issues:


• There is a firewall preventing the gateway from connecting to the target SMB service.• 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.

If telnet succeeds, a firewall is causing the problem. Otherwise, there is a problem with the SMBservice.

Do the following:

• View the control panel, services, and check if the Server service is running.• 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 thosesystemsProblem

The slow discovery of Windows 2003 SP1 systems, or applications running on those systems, mightbe a result of a memory leak in the WMI service.

SolutionEnsure that the following hotfix, available from Microsoft, is installed: http://support.microsoft.com/kb/911262

Windows 2000 systems are not discoveredProblem

If Windows 2000 systems are not discovered, the problem might be because an unsupported versionof the netstat program installed on the target system. The netstat program is used to get TCP portinformation during discovery. Windows 2000 systems use a different version of the netstat programfrom the one installed on systems running later versions of Windows.

SolutionEnsure that the following hotfix, available from Microsoft, is installed: http://support.microsoft.com/kb/907980

TADDM Discovery of Windows XP targets when local firewall is enabled.Problem

Windows XP-based targets generally have the local firewall that is enabled for added security.

The TADDM discovery on these computers fails with following error if the firewall blocks the discovery:

CTJTP1161E The application cannot establish the following WMI session:SessionClientException: SELECT BuildVersion FROM Win32_WMISetting failed(0x800706ba: The RPC server is unavailable.): 0x800706ba: System.Runtime.InteropServices.COMException (0x800706BA): The RPC server isunavailable.

SolutionTo discover a Windows target when there is a Local firewall that is enabled, restrict the RPC ports onWindows XP target to a narrow range, and then open those ports on the firewall.

Follow these steps to restrict the DCOM ports:

1. Goto Control Panel.


http://support.microsoft.com/kb/911262




2. Select Administrative Tools.3. Select Component Services.4. Select Computers.5. Right click My Computerand open Properties.6. Select Default Protocolstab.7. Double-click Connection-oriented TCP/IP.8. Select Add in COM internet services window.9. Add a port range, for example, 5000-5050. Click OK.

10. Restart the computer.

Add the DCOM ports to the firewall exception list.

Follow these steps to allow the ports in local firewall:

1. Goto Control Panel.2. Click Windows Firewall.3. Click Exceptions.4. Click Add Port .5. Add each of the DCOM ports one by one to the restrictions.

Sensor fails on targets with Tectia SSH Server because of the 'failed to copy file'errorProblem

Sensor fails on targets with Tectia SSH Server, and the log files contain the following message:

session.Ssh2SessionClient - failed to copy file: AAAA to: BBBB with retray 0java.io.EOFException: SSHSCP1: premature EOF

SolutionTo solve the problem, complete the following steps:

1. Install Tectia SSH Client on the TADDM server.2. Configure TADDM to use external Tectia scp command. Set thecom.collation.platform.os.scp.command property in the collation.properties file topoint to the Tectia scp command. For example:

com.collation.platform.os.scp.command=C:\\SshTectia\\SSH Tectia Client\\scp2.exe

You can define the preceding flag only for the selected IPs and scope sets. For example:

com.collation.platform.os.scp.command.10.11.12.13=C:\\SshTectia\\SSH Tectia Client\\scp2.execom.collation.platform.os.scp.command.scopesetA=C:\\SshTectia\\SSH Tectia Client\\scp2.exe

Note: When TADDM is in FIPS 140-2 compliant mode, using the external scp command mightaffect security. In such case, you must make sure that the used SCP program is FIPS-compliant.

Windows Storage sensor error is received when windows computer system scriptsensor is runProblem

Storage sensor error is received when windows computer system script sensor is invoked. InTopologyManager.log file following error was received:

com.ibm.tivoli.namereconciliation.common.NrsDatabaseException: 2002. The length of a string provided has exceeded the maximum length. Shorten the string length


andtry the request again.com.collation.platform.model.topology.sys.windows.WindowsComputerSystem ERROR sys.SoftwareComponentJdo - [Jdo.E.5] Naming exception - guid not found{softwareVersion=6.0.1.163 NULNULNULNULNULNULNULNULNUL…….}

Here the version of the software contains special characters, which are visible as “NULNUL…..” due towhich the data length exceeds for an intermediate table column length limit.

SolutionTo resolve this error:

1. Set following property in collation.properties file:

com.ibm.cdb.WindowsSoftwareComponent.VersionForNaming.TrimToLength=true

2. Rerun the discovery. This truncates the software version to 192 characters. When the lengthexceeds this length and then it will go for saving with the truncated value.

Korean language characters not captured correctly during discovery

ProblemWhen WindowsComputerSystemSensor in script mode discovers the data that contains characters inthe Korean language on target, then the Korean language characters are not captured correctly, andinvalid characters are displayed in the DMP. This problem is due to the discovered data being read bythe sensor with default coding ISO_8859_1.

SolutionTo resolve this error, the sensor must read the discovered data from the target with encoding in UTF-8format. This can be done by configuring the following property to ‘true’ in collation.propertiesfile on the discovery server:

com.ibm.cdb.discover.OutputFileSplittingProcess.DefaultReadEncoding=true

Once the above property is configured, UTF-8 encoding will be used for encoding the discovered dataand it will read, store, and display the data in the correct format.

Storage sensorsStorage sensors discover the storage that is used in the environment.

EMC Storage Scope sensorThe EMC Storage Scope sensor discovers storage resources that are related to storage area network(SAN) by extracting data from an EMC Storage Scope database.

The sensor discovers such storage resources as storage arrays, hosts, switches, fabrics, zones, storagevolumes, switch ports, file systems, and disk drives. Some of those resources, like data that is related tohosts or to switches, can also be discovered by the Host storage sensor or the Fibre Channel switchsensor.

The EMC discovery is performed by two sensors, the EMC Storage Scope sensor and the EMC StorageScope Detail sensor. The first one discovers general attributes of StorageSubSystem and full details of FCSwitch, Fabric, Zone and ZoneSet. Then, the sensor starts the Detail sensor that discovers details of EMCarrays and hosts. You can specify the number of arrays discovered by each of the Detail sensors by editingthe arraysDiscoveryChunk parameter.

Sensor name that is used in the GUI and logsEMCStorageScopeSensor, EMCStorageScopeDetailSensor


Prerequisites• You must copy the following Oracle JAR files from the discovery endpoint to the dist/osgi/plugins/com.ibm.cdb.discover.sensor.app.srm.emccommon_1.0.0/lib/oracledirectory:

– ojdbc14.jar– oraclepki.jar– ojpse.jar

Limitations• To avoid duplicates, you must run the Level 2 discovery of endpoints that are discovered by EMC

Storage Scope sensor.• To reduce the number of discovered objects that might result in the Out of Memory errors, the EMC

Storage Scope Detail sensor discovers only one SCSI Path for each Volume, even if more are available.TADDM uses the SCSI Paths to create relationship between a computer system and a StorageSubSystem. The Paths are retrieved from the SRMHostArrayPath table.

• When you run a discovery, StoragePools are not discovered.

Security issues• If you enable SSL on the EMC Oracle database, you must add the cwallet.sso file to the access list.

Model objects with associated attributesThe EMC Storage Scope sensor creates model objects with associated attributes. The attributes indicatethe type of information that the sensor collects about storage resources that are stored in EMC StorageScope database.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.dev.BasedOnExtent


storage.HostBusAdaptor

• Name• Parent• WordlWideName

dev.DiskDrive

• DiskSize• Name• Parent• SerialNumber• Type• Vendor• Revision• Status• DiskSpeed


dev.FCPort

• Description• Parent• PermanentAddress• PortNumber• PortType• Status

dev.FCVolume

• Capacity• Name• Parent• BasedOn• FreeSpace

net.IpAddress

• DotNotation• StringNotation

net.IpInterface

• IpAddress• Parent

relation.ConnectedTo

• Source• Target• Type

storage.Fabric

• Fcswitch• Name• SourceToken• ZoneSets• Zones

storage.FCSwitch

• FCPorts• ManagementURL• Manufacturer• Model• Name• ROMVersion• SerialNumber• Type• WorldWideName

storage.StorageSubSystem

• AllocatedCapacity


• AvailabilityState• AvailableCapacity• CacheSize• FCPorts• Fqdn• Manufacturer• Members• Model• ROMVersion• SerialNumber• Type• VolumeGroupCapacity• VolumeGroupFreeSpace

storage.StorageVolume

• Capacity• Name• Parent• RedundancyMethod• SourceToken

storage.Zone

• Active• Name• Parent

storage.ZoneSet

• Active• Name• Parent• Zones

Multiple operating systems:sys.aix.Aixsys.hpux.HpUxsys.linux.Linuxsys.OperatingSystemsys.sun.Solarissys.vmware.VmwareESXsys.windows.WindowsOperatingSystem

These model objects are associated with the following attributes:

• FQDN• OSConfidence• OSName• Parent

Multiple computer environments:sys.aix.AixUnitaryComputerSystem


sys.ComputerSystemsys.hpux.HpUxUnitaryComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.SunSPARCUnitaryComputerSystemsys.vmware.VmwareUnitaryComputerSystemsys.windows.WindowsComputerSystem


• Devices• FCPorts• FileSystems• FQDN• IpInterfaces• Model• OSInstalled• OSRunning• Signature• Type• Name

Multiple file systems:sys.LocalFileSystemsys.sun.SolarisFileSystemsys.unix.UnixFileSystemsys.windows.WindowsFileSystem


• AvailableSpace• Capacity• MountPoint• Parent• Type

dev.BasedOnExtent


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

Configuring the access listThe sensor requires the following credentials for a successful discovery:

• Windows computer system credentials for the EMC Storage Scope server• Oracle credentials for the EMC database. If you enable SSL for the JDBC connection, you must also add

the cwallet.sso file to the access list.


Configuring the discovery profileThe EMC Storage Scope sensor is enabled by default in the Level 3 discovery profile.

Restriction: The Host storage sensor and the Fibre Channel switch sensor also discover hosts andswitches. If both of them are enabled, the resources might be discovered twice.

Create a new profile to modify the following attributes:discoverHosts

The default value for the discoverHosts attribute is true. The sensor discovers host-related data, forexample, ComputerSystem, disks, FC ports, FC volumes, storage volumes, local file systems, and filesystem services.

If the value is false, host-related data is not discovered by the sensor.

discoverSwitchThe default value for the discoverSwitch attribute is true. The sensor discovers switch related data,for example, switch, switch ports, and FC ports.

If the value is false, switch related data is not discovered by the sensor.

discoverArraySerialNumberStartsWithBy default, the sensor discovers all of the arrays found. You can specify this attribute to limit theirnumber. For example, if you want to discover arrays with a serial number that starts with APM, use thefollowing parameter:

discoverArraySerialNumberStartsWith=APM

arraysDiscoveryChunkThe default value for the arraysDiscoveryChunk attribute is 10. This attribute specifies the number ofarrays that are processed by each EMC Storage Scope Details sensor.

Restriction: If the value is to high, the discovery might result in the Out of Memory errors.

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

The sensor cannot connect to the EMC databaseProblem

The sensor fails because it cannot connect to the EMC database.Solution

Make sure that your credentials to the EMC database are correct, and that you copied all required JARfiles. If you enable SSL, you must also add the cwallet.sso file to the access list.

The sensor does not discover the host computer systemsProblem

The sensor does not discover the host computer systems.Solution

The sensor can discover only the host systems that are managed by the EMC Control Center and thatare synchronized with EMC Storage Scope database. The hosts must also have a relationship to FCSwitch or Storage SubSystem.

The discovery takes too long to completeProblem

The discovery takes too long to complete.


SolutionThe Host storage sensor and the Fibre Channel switch sensor also discover hosts and switches. Ifboth of them are enabled, the resources might be discovered twice. Check your discovery.

The discovery finishes with the CTJTD2312E errorProblem

The discovery finishes with the CTJTD2312E error.Solution

In the sensor log file, find the targetDb.HOSTNAME property and ensure that the host can beresolved from the TADDM server.

The database lock occursProblem

The database lock occurs when two sensors try to store similar data in the database at the same time.Solution

By default, all Detail sensors store their data at the same time. You can change the following propertyto make them do it one by one:

com.collation.discover.observer.topopumpdeadlockstrategy=avoid

Restriction: The discovery time might increase if the sensors store their data in a sequence.

EMC ViPR SRM SensorThe EMC ViPR SRM Sensor discovers storage resources that are related to storage area network (SAN)and utilizes the EMC ViPR SRM for discovery. The sensor discovers such storage resources as storagearrays, hosts, hypervisors, switches, fabrics, zones, storage volumes, switch ports, file systems and diskdrives.

Sensor name that is used in the GUI and logsEMCViprSRMSensor

Elements discovered by the sensorThe sensor discovers the following elements/model objects:

• StorageSubSystem• Fabric• Zone• ZoneSet• FCSwitch• FCPort• IpInterface• FCVolume• DiskDrive• BasedOnExtent• OperatingSystem

– Linux– Aix– HpUx


– WindowsOperatingSystem– Solaris

• ComputerSystem

– LinuxUnitaryComputerSystem– AixUnitaryComputerSystem– HpUxUnitaryComputerSystem– WindowsComputerSystem– SUNSPARCUnitaryComputerSystem

• LocalFileSystem• HostBusAdaptor• ConnectedTo• SCSIPath• SCSIProtocolEndPoint

Prerequisites and LimitationsBefore you run this sensor, the following prerequisites must be met:

• EMC ViPR SRM must have REST API interface enabled• EMC ViPR SRM sensor relies on ViPR SRM REST APIs for discovery, hence ViPR SRM must have already

discovered the components to be considered during the sensor execution• If host related details (including the computerSystem to storage mappings) needs to be discovered,

EMC ViPR SRM must have Host Discovery enabled• If switch related details needs to be discovered, EMC ViPR SRM must have Switch Discovery enabled• Hosts or Hypervisors having valid or non-empty "Domain" configured and discovered in EMC ViPR SRM

shall be discovered by this sensor, else it might result in duplicate Computer systems• EMC ViPR SRM Sensor captures the metrics or capacities for Arrays or Volumes or Pools etc. based on

last available value (latest value) that is present in EMC ViPR SRM• Discovery of storage Arrays other than EMC VMAX Arrays is not supported• Cisco MDS or Nexus Switch discovery is not supported• SSL Certificates based connection with EMC ViPR SRM is supported• Discovery of Virtual Machines is not supported

Model objects with associated attributesThe EMC ViPR SRM Sensor creates model objects with associated attributes. The attributes indicate thetype of information that the sensor collects about the EMC VMAX storage.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.storage.StorageSubSystem

• AllocatedCapacity• AvailabilityState• AvailableCapacity• FCPorts• Fqdn• Manufacturer• Members• Model


• ROMVersion• SerialNumber• Type• VolumeGroupCapacity• VolumeGroupFreeSpace

storage.StoragePool

• AnsiT10Id• Name• LocationTag• RaidLevel• Label• Capacity• TotalManagedSpace• StorageSubSystem


• Capacity• Name• Parent• IOGroup

dev.FCVolume

• BlockSize• Type• NodeWWN• FCPLun• Name• Parent

storage.Fabric

• Fcswitch• Name• WorldWideName• SourceToken• ZoneSets• Zones

storage.Zone

• Active• Name• Parent

storage.ZoneSet

• Active• Name• Parent• Zones


storage.FCSwitch

• FCPorts• ManagementURL• Manufacturer• Model• Name• ROMVersion• SerialNumber• Type• WorldWideName• IpInterface

dev.FCPort

• Description• Parent• PermanentAddress• PortNumber

net.IpAddress


net.IpInterface



• Name• Parent• WordlWideName

Multiple operating systems

• sys.aix.Aix• sys.hpux.HpUx• sys.linux.Linux• sys.sun.Solaris• sys.windows.WindowsOperatingSystem• sys.vmware.VmwareESX


• FQDN• OSConfidence• OSName• Parent

Multiple computer environments

• sys.aix.AixUnitaryComputerSystem• sys.hpux.HpUxUnitaryComputerSystem


• sys.linux.LinuxUnitaryComputerSystem• sys.sun.SunSPARCUnitaryComputerSystem• sys.windows.WindowsComputerSystem• sys.vmware.VmwareUnitaryComputerSystem


• FCPorts• FQDN• IpInterfaces• Model• OSInstalled• BIOSManufacturer• OSRunning• Signature• Type• Name

SCSIPath

• ArrayVolume• LUN• ManagedSystemName• Parent• HostEndPoint

SCSIProtocolEndPoint

• Name• ManagedSystemName

dev.DiskDrive

• DiskSize• Name• Parent• SerialNumber• Type• Vendor• Revision• Status• DiskSpeed• Model• LocationTag




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

Configuring the access listThe sensor requires the following credentials for a successful discovery:

• Windows computer system credentials for the EMC Storage Scope server• Oracle credentials for the EMC database. If you enable SSL for the JDBC connection, you must also add

the cwallet.sso file to the access list.

Configuring the discovery scopeTo enable discovery of storage components, you must provision EMC ViPR SRM IP address in thediscovery scope.

EMC ViPR SRM Sensor will get invoked from the Port Scan Sensor, if matching port is found. In PortSensorconfiguration, “emcsrmPorts” is configured with default ports for EMC ViPR SRM, for example, portnumber 58443 and 58080.

If non-default port is being used for EMC ViPR SRM, then “emcsrmPorts” needs to be updated.

Configuring the access listEMC ViPR SRM Sensor requires separate provisioning of access-list entries corresponding to EMC ViPRSRM user credentials.

An access list credential needs to be provisioned by selecting the “Component Type” as 'EMC VIPR SRM'and provisioning username and password to access the EMC ViPR SRM.

Before using the EMC ViPR SRM Sensor, you must configure it.

Configuring the discovery profileBy default, the EMC ViPR SRM Sensor is enabled for a Level 3 discovery. The sensor discovers informationrelated to VMAX storage resources. To create the discovery profile, complete the following procedure:

1. In the Discovery drawer of the Discovery Management Console, click Discovery Profiles.2. In the Discovery Profiles window, click New.3. To enable this sensor, select EMCViprSRMSensor in the discovery profile.4. On the Sensor Configuration tab, select EMCViprSRMSensor sensor and click New.5. In the 'Create Configuration' window, type the name and description for your configuration, and select

Enable Configuration check box.6. In the Configuration section of the Create Configuration window, sensor properties can be configured.7. Click OK to return to the Discovery Profiles window.8. In the Discovery Profiles window, click Save.

EMC ViPR SRM sensor propertiesYou can modify the following properties and attributes:

enableSSLThis option can be configured for SSL Certificate based ViPR SRM access.

• When enableSSL option is false, then http mode will be used for EMC ViPR SRM discovery using SRMREST APIs

• When enableSSL option is true and at least one of the Key Store Certificate, Key Store Pass Phraseand SSL Type parameters is not configured in SSL Discovery Settings in Access List for EMC ViPRSRM, then https mode (without certificate) will be used for EMC ViPR SRM discovery using SRMREST APIs


• When enableSSL option is true and Key Store Certificate, Key Store Pass Phrase and SSL Type isconfigured in SSL Discovery Settings in Access List for EMC ViPR SRM, https mode with certificatewill be used for EMC ViPR SRM discovery using SRM REST APIs

Default value: false.

Note: Port 58080 will be used for http mode discovery and port 58443 will be used for https mode ofdiscovery.

enableHostDiscoveryThis option can be configured to enable or disable Host Discovery.If this option is set as true, Hosts and Hypervisors will be discovered. If the option is set as false,neither Hosts nor Hypervisors will be discovered.Default value: true.

enableSwitchDiscoveryThis option can be configured to enable or disable Switch Discovery.Default value: true.

arrayDiscoveryChunkThis option limits the number of storage arrays (VMAX) for detailed discovery (Max limit 20).arrayDiscoveryChunk value will be capped at 20, if count > 20 is specified in the configuration.If this option is configured with value 0, then it means that no limits are to be placed.Default value: 10

discoverArraySerialNumberStartsWithThis option limits Array discovery for VMAX Arrays matching the starting serial number characters.

Additional configuration optionsSome of the additional configurations (as listed below) can be done in emcvipr.properties file present ingiven below sensor plugin directory:

/opt/IBM/taddm/dist/osgi/plugins/com.ibm.cdb.discover.sensor.app.srm.emc.vipr_1.0.0

Here are the details of these configurations:com.ibm.cdg.discover.sensor.app.srm.emc.vipr.conn.timeout

This specifies the VIPR SRM REST API connection timeout (in seconds). Capped at 300 sec.Possible Values: 1-300 (sec)Default Value: 30 (sec)

com.ibm.cdg.discover.sensor.app.srm.emc.vipr.conn.restimeoutThis specifies the VIPR SRM REST API response timeout (in seconds). Capped at 300 sec.Possible Values: 1-300 (sec)Default Value: 30 (sec)

com.ibm.cdg.discover.sensor.app.srm.emc.vipr.conn.limitThis specifies the maximum number of elements to return for Capacities or Metrics SRM REST APIQuery.This option is utilized during array, storage group and storage pool capacities retrieval to ensure thatall the arrays or volumes or pools are present in the returned results.By default, SRM will trim the REST API response till 500 entries.Possible Values: 1-anyDefault Value: 1000

Note: There is a hard limit of 10,000 configured in the server. For any other query, if the number ofreturned elements is greater than the hard limit, an error will be returned.


com.ibm.cdg.discover.sensor.app.srm.emc.vipr.conn.period.daysThis value will specify how much number of days, old reports or scan by EMC ViPR SRM, shall beconsidered to get the capacities or metrics for Array, volumes, storage pools etc.By Default, upto 7 days old scan reports can be utilized for array, pool, volume, etc. capacities.Possible Values: 1-365 (days)Default Value: 7 (days)

Note: Any negative values specified for this property will be treated as positive value.

com.ibm.cdg.discover.sensor.app.srm.emc.vipr.conn.passivehostdiscoveryThis property can be configured as true to be able to discover hosts that are passively discoveredhosts or hypervisors in EMC.For discovering passive hosts, this property and enableHostDiscovery option in sensor propertiesshould be enabled. Only Hostname and FC Ports will be discovered for these passive hosts. Thisoption can be used only when Passive Host discovery is enabled in EMC ViPR SRM.This option shall be used only when there are hosts or hypervisors that are being discovered by otherTADDM sensor (LinuxComputerSystemSensor, WindowsComputerSystemSensor,VmwareESXiComputerSystemSensor, HostStorageSensor etc.). Otherwise, this will leave partial orshallow computerSystem objects with just Hostname and FC Ports information retrieved from EMCViPR SRM.Default Value: false

Note:

1. In Passive Host Discovery, Hosts or Hypervisors will be discovered irrespective of type ofCOMPUTER_SYSTEM_TYPE set.

2. Reconciliation with the actual ComputerSystem MO (discovered using TADDM computer Systemsensors) will be done based on Hostname only. Thus, in case of non-unique hostname(s), passivehost discovery will not be supported.

COMPUTER_SYSTEM_TYPEThis option is to configure or run discovery on basis of type of COMPUTER SYSTEM that is to bediscovered via EMC ViPR SRM sensor.COMPUTER_SYSTEM_TYPE can be configured as follows:

• COMPUTER_SYSTEM_TYPE set as HOST- only HOSTs will be discovered• COMPUTER_SYSTEM_TYPE set as HYPERVISOR- only HYPERVISORs will be discovered• COMPUTER_SYSTEM_TYPE set as CS_ALL- both HOSTs and HYPERVISORs will be discovered

This configuration will be applicable only when enableHostDiscovery is configured as true.Default Value: CS_ALL

com.collation.discover.agent.EMCViprSRMSensor.timeoutThis is an optional property which can be configured if there is a sensor timeout. By default, thissensor will utilize the global timeout value of 10 minute. To appropriately set the sensor timeout,configure this property in the collation.properties fileFor example, following line will configure timeout duration to 2 hour:com.collation.discover.agent.EMCViprSRMSensor.timeout=7200000

EMC ViPR SRM supported versionFollowing are the supported versions of EMC ViPR SRM:

• EMC ViPR SRM 4.1u1 - 4763• EMC M&R 6.8u2 – 69899


Troubleshooting the sensorThis topic describes common problems that occur with the EMC ViPR SRM sensor and presents solutionsfor those problems.

The sensor cannot discover all the Arrays configured in EMCProblem

The sensor is not able to discover all the arrays, as visible in the EMC ViPR SRM GUI.Solution

EMC ViPR SRM sensor supports discovery of only VMAX arrays. So only the VMAX arrays configured inEMC will be discovered by EMC ViPR SRM sensor.

The sensor does not discover the host computer systemsProblem

The sensor does not discover the host computer systems.Solution

The sensor can discover only hosts that have all the parameters configured present against theHOST.api query in emcvipr.config file, present in given below sensor plugin directory:


If any of the below parameter is not set in HOST.api, then no hosts will be returned in the REST APIresponse and therefore, no hosts will be discovered.

HOST.name=HOSTHOST.api=fields=devtype,device,ip,vendor,hostname,model,osarch,virtual,fqdn,devdesc\ &filter=devtype%3D%27Host%27

The sensor does not populate the capacitiesProblem

The sensor does not populate the capacities for Storage Subsystem(Arrays), Volumes or Pools.Solution

Capacities might not be populated for StorageSubsystems(Arrays), if the value or number of days setfor the property “com.ibm.cdg.discover.sensor.app.srm.emc.vipr.conn.period.days” is not set as perthe last scan done or last report generated in EMC.Also, it could be possible that, capacities are discovered only for some volumes, arrays or pools, thiscould be due to the results getting trimmed in the query result. By default, SRM will trim the REST APIresponse till 500 entries. You can increase the limit of records by increasing the value correspondingto the property “com.ibm.cdg.discover.sensor.app.srm.emc.vipr.conn.limit” present inemcvipr.properties file, present in given below sensor plugin directory:


Fibre Channel switch sensorThe Fibre Channel switch sensor discovers Fibre Channel (FC) switches and information about FC ports.

Sensor name that is used in the GUI and logsFCSwitchSensor


Model objects with associated attributesThe Fibre Channel (FC) switch sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about Fibre Channel switch resources in your ITenvironment.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.dev.FCPort

• DisplayName• PortNumber• DeviceID• PermanentAddress• PortType• Speed



storage.FCSwitch

• Name• Description• WorldWideName• Model• Manufacturer• SerialNumber• Version

sys.ControlSoftware

• Name• VersionString



The sensor is not enabled by default. To enable the sensor, you must create a discovery profile, and thenenable the sensor from the new profile. The sensor requires, additional sensors to be enabled in theprofile:

• AnchorSensor• PingSensor• PortSensor• SessionSensor• SnmpMib2Sensor














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

Incomplete switch information discoveredProblem

The sensor completes the discovery but does not collect all the details about the switches.Solution

Verify that the following data is available:

• Fibre Alliance MIB (FC-MGMT MIB)• Cisco MIB (CISCO-FC-FE MIB)• Brocade switch model information (switch.html)

Host resources sensorThe host resources sensor uses the host resources MIB to discover operating system details such asmemory size, file system, installed software with date and type, Media Access Device, and logical storageareas.

Details about the logical storage areas can be useful for troubleshooting "out of memory" and "out ofbuffers" problems.

Sensor name that is used in the GUI and logsHostResourcesSensor

LimitationsFile systems discovered by the sensor are not displayed in the user interface. This restriction applies tocomputer systems running on operating systems other than Windows operating system. Run the api.shscript to see the file systems discovered by this sensor.



• Memory Size: .1.3.6.1.2.1.25.2.2.0• Storage Table: .1.3.6.1.2.1.25.2.1.2• Device Type: .1.3.6.1.2.1.25.3.1.1• Media Access Device: .1.3.6.1.2.1.25.3.2.1.1• Installed Software: .1.3.6.1.2.1.25.6.3.1.1


• dev.MediaAccessDevice• sys.ComputerSystem sys.OperatingSystem• sys.FileSystem• sys.SoftwareComponent













Host storage sensorThe host storage sensor discovers the storage that is attached to a host computer system, includingstorage area network (SAN) storage. This sensor extends the storage discovery that is provided by thestorage sensor.

The host storage and storage sensors discover the same storage resources, for example, disks, partitions,logical volumes, physical volumes, and file systems. The host storage sensor also discovers the followingstorage resources:

• Fibre Channel (FC) volumes• FC ports• Host bus adapters


Sensor name that is used in the GUI and logsHostStorageSensor

PrerequisitesFor 64-bit Linux targets

The 32-bit glibc library is required, only when 32-bit version of collectionEngine binary isused by the sensor (Default).

If collectionEngineBuild_64_Bit option is set to true, then 32-bit glibc is not required.

LimitationsWhen you discover storage attached to a target computer using the storage sensor, do not carry out adiscovery on the same system using this sensor.

You must install Vendor's host bus adapter (HBA) API library files (32-bits). Vendor’s 32-bitsHBA API library files are not needed, when sensor uses 64-bit collection engine binary.

The sensor does not discover the ZFS file systems on the Solaris target systems.

Do not run the sensor on AIX LPARs, where the LPAR's configuration is attached to the BR8470 FCoEswitch that runs FOS v6.4.3_dcb in Access Gateway mode. It leads to an unexpected behavior of systemsthat are connected to that FC Switch. Use FOS7.0.2e, or later.

Security issuesBy default, root user privileges are required to discover SAN resources in UNIX environments. Typically,this escalation is done by setting the file access permissions using the setuid (set-user-ID mode bit)term or by using the sudo command.

Model objects with associated attributesThe Host storage sensor creates model objects with associated attributes. The attributes indicate thetype of information that the sensor collects about storage resources in your IT environment.



dev.ControlledBy

• Controller• Device

dev.Controller

• Name

dev.DiskDrive

• Description• DiskSize• Name• Type


dev.DiskPartition

• BlockSize• Name• NumOfBlocks

dev.FCPort

• PermanentAddress• PortType• Speed

dev.FCVolume

• BlockSize• Controller• DeviceID• FCPLun• Name• NodeWWN• NumOfBlocks• PortWWN• RealizedBy• SCSIBus• SCSILun• SCSITarget• Type

dev.RealizesExtent


dev.SCSIProtocolController

• EndPoints• FCPorts• Name


• Name• WorldWideName

dev.SCSIVolume

• BlockSize• DeviceID• Name• NumOfBlocks• RealizedBy• SCSIBus• SCSILun• SCSITarget• Type


dev.StorageExtent

• BlockSize• DeviceID• Name• NumOfBlocks

dev.StorageVolume

• BlockSize• DeviceID• Name• NumOfBlocks• RealizedBy• Type

phys.physpkg.Card

• FWRevision• Manufacturer• Model• SerialNumber


• Name• PhysicalPackage• SCSIProtocolControllers• WorldWideName

sys.LocalFileSystem

• AvailableSpace• Capacity• Label• MountPoint• StorageExtent• Type

sys.NFSFileSystem

• AvailableSpace• Capacity• ExportName• MountPoint• ServerName


• AvailableSpace• Capacity• Description• MountPoint• Type


sys.windows.WindowsFileSystem

• AvailableSpace• Capacity• Description• MountPoint• Type


Copying the collection engine file to a location accessible to the target host systemThe 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 hostsystem. After the discovery is complete, the collection engine file is deleted from the host. Root privilegesare required to run the collection engine program. Copying an application to a host system that requiresroot privileges can introduce a security risk. To avoid this risk, the sensor supports a configuration thatallows 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 isaccessible to the target host system.

To copy and configure the collection engine file, complete the following steps:

1. From the taddm_home/dist/osgi/plugins/com.ibm.cdb.discover.sensor.dev.hoststorage_7.2.0/bin/collection-enginedirectory on the TADDM server, copy the file to a location that is accessible 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:

• For Windows systems, edit the System PATH environment variable on the host system, and type thelocation of the collection engine directory.

• For all other systems, edit the com.collation.discover.agent.path in the collation.properties fileon the TADDM server, and type the location of the collection engine directory. Specify the location ofthe collection engine directory for the appropriate target operating system.

• Modify the discovery profile for the Host storage sensor on the TADDM server. Type the path to thecollection engine directory in the CollectionEnginePath or the CollectionEngineWindowsPath attributeor both, if required.

4. Modify the discovery profile for the Host storage sensor on the TADDM server. Set thedeployCollectionEngine 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 requireprivilege escalation. Typically, this escalation is done by setting the file access permissions using thesetuid (set-user-ID mode bit) term or by using the sudo command. For Windows operating systems,the discovery user must be a member of the Administrators group.

Configuring the discovery profileThe Host storage sensor, is not enabled by default. To enable the sensor, you must create a discoveryprofile and then enable the sensor from the new profile.

The collection engine uses the HBA (host bus adapter) API to discover the HBAs and FC volumes that areconfigured on the host system. For a successful discovery, the vendor's HBA API library must be installedand configured correctly on the host system.

The following attributes can be modified:


deployCollectionEngineWindowsThe default value for the deployCollectionEngineWindows attribute is true. The sensor copies thecollection engine file to a location on the Windows target host system. After the discovery is complete,the collection engine file is deleted from the host. The location is entered in thecollectionEngineWindowsPath attribute. If no path is specified on Windows systems, the collectionengine file is copied to the TEMP directory.If the value is false, the collection engine file is not copied.

deployCollectionEngineThe default value for the deployCollectionEngine attribute is true. The sensor copies the collectionengine file to a location on the target host system. After the discovery is complete, the collectionengine file is deleted from the host. The location is entered in the collectionEnginePath, or thecollectionEngineWindowsPath attribute. If no path is specified on Windows systems, the collectionengine file is copied to the TEMP directory. For all other systems, the collection engine file is copied tothe 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.

Important: In TADDM 7.3.0.4, and later, this attribute does not apply to the Windowstargets. Instead, use the deployCollectionEngineWindows attribute.

collectionEnginePathThere is no default value for the collectionEnginePath attribute. Enter the absolute path to the UNIXcollection engine directory, if required.

collectionEngineWindowsPathThere is no default value for the collectionEngineWindowsPath attribute. Enter the absolute path tothe Windows collection engine directory, if required.

Entering the Windows path when the directory is on a network drive (created by using the net usecommand), might not work. Instead, enter the Windows path by using the UNC (Universal NamingConvention) method. For example, \\hostname\share\CollectionEngine.

collectionEngineSudoCommandThere is no default value for the collectionEngineSudoCommand attribute. Enter the command touse for privilege escalation on UNIX systems.

collectionEngineTimeoutThe default value for the collectionEngineTimeout attribute is 30. This value specifies the timeinterval in minutes before a timeout occurs during a discovery.

collectionEngineForceUniqueNameThe default value for the collectionEngineForceUniqueName attribute is false. If the value isfalse, the collection engine is not renamed when the collection engine is copied to the targetsystem. If the value is true, a time stamp is added to the name of the collection engine before it iscopied to the target system.

If you want to use sudo to give the discovery user permission to run the collection engine, then thecollection 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 run at the same time,against the same target systems, collisions can occur when deploying the collection engine. Insituations like this, the collectionEngineForceUniqueName attribute can be set to true to force thename of the collection engine to be unique on the target system. If this attribute is set to true, sudocannot 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.





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 Hoststorage sensor carrying out the discovery can require privilege escalation. Typically, this escalation isdone by setting the file access permissions using the setuid (set-user-ID mode bit) term or by using thesudo command.


The sensor uses the following entries, which explicitly specify the location of the collection enginedirectory, in the collation.properties file:com.collation.discover.agent.path.Linuxcom.collation.discover.agent.path.SunOScom.collation.discover.agent.path.HP-UXcom.collation.discover.agent.path.AIXcom.collation.discover.agent.path.Vmnix

You can specify each of these properties as a scoped property by appending an IP address or a scope setname to the property, for example com.collation.discover.agent.path.Linux.1.2.3.4.

If the collection engine exits on multiple target computers that have the same operating system, but thecollection engines reside in different paths, enter the paths in the collation.properties file.Separate each unique path with a colon.

Troubleshooting the sensorThis topic describes common problems that occur with the Host storage sensor and presents solutions forthose problems.

Commands fail because of insufficient privilegesProblem

Command failures occurred due to permissions denied errors and are recorded in the log files.Solution

Verify that the commands that require privilege escalation are configured correctly.

Discovery takes a long time to runProblem

The discovery takes a long time to run.Solution

Check whether the StorageSensor sensor is enabled and disable it. If both sensors are enabled, someof the storages resources are discovered twice.

Host storage data is not discoveredProblem

Host storage data is not discovered.Solution

Verify that the vendor's host bus adapter (HBA) API library files are installed and configured correctlyon the host system. Missing library files might be identified in the HostStorageSensor log file.


WWPN and WWNN information are not displayedProblem

The worldwide port name (WWPN) and worldwide node name (WWNN) for an FC volume are notdisplayed.

SolutionTADDM uses the HBA API for FC volume discovery. The HBA API provides a mapping from the OSidentification of a SCSI volume to the FC representation of the volume. The FC representation includesthe WWPN of the port from the HBA that finds the volume. On multiport HBAs, there is no way todetermine which port a SCSI volume applies to. This limitation is in the HBA API. The HBA APIspecification was updated to address this issue, but the change might not be implemented in all HBAAPI libraries. Ensure that the latest version of the HBA vendor's HBA API library is installed on thetarget host system. In summary, if the HBA API is unable to provide the mapping of a SCSI volume toits FC representation, then the WWPN and WWNN cannot be determined.

Expected number of HBAs are not displayedProblem

TADDM does not display the expected number of HBAs.Solution

TADDM uses the HBA API for HBA discovery. For each adapter that the HBA API returns, TADDMcreates an HBA model object. The adapters WWNN is used by TADDM to name the HBA. The numberof adapters might not match the number of physical HBA cards that are installed in the host computersystem, or the number of WWNNs returned by the basic system commands.How the HBA API library interprets adapters and WWNNs are determined by the HBA vendor's, HBAAPI library implementation. For example, some vendors might represent a multiport HBA card thatuses one adapter with one WWNN. Other vendors can represent a multiport HBA card that uses oneadapter per port, with each adapter having its own unique WWNN.

Port type and port speed are not displayedProblem

The port type and port speed for an FC port are not displayed.Solution

TADDM uses the HBA API for FC Port discovery. However, some HBA API libraries might not supportthese attributes, or the HBA vendor's HBA API library might need to be updated. Ensure that thelatest version of the HBA API library is installed on the target host system. If the HBA API librarycannot determine the port type and port speed, then these attributes are not displayed.

SCSI bus, SCSI target, and SCSI LUN are not displayed correctlyProblem

The SCSI bus, SCSI target, and SCSI LUN for an FC volume are not displayed or the correct values arenot displayed.

SolutionTADDM uses the HBA API to discover SCSI information about an FC volume. However, some HBA APIlibraries 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 thelatest version of the HBA API library is installed on the target host system. If the HBA API librarycannot determine the SCSI information, then these attributes are not displayed or might displayincorrect values.

FC volume information is not displayed correctlyProblem

The FC volume information is not displayed or does not display correct values.


SolutionTADDM uses the HBA API to discover information about an FC volume. However, if there is a problemwith the HBA API library, TADDM might display incorrect values for some FC volume attributes. Forexample, block size. To resolve this problem, ensure that the latest version of the HBA API library isinstalled on the target host system and configured correctly. If the HBA API library is not configuredcorrectly, FC volume attributes might not display or might display incorrect values.

BR8470 FCoE switch causes HostStorageSensor to negatively impact systems thatare connected to the switchProblem

When you are running HostStorageSensor on AIX LPARs, where the LPAR's configuration is attachedto the BR8470 FCoE switch that runs FOS v6.4.3_dcb in Access Gateway mode, it leads to anunexpected behavior of systems that are connected to that FC switch.

SolutionIt is a known FOS issue. To solve it, upgrade to FOS7.0.2e, or later.

IBM Tivoli Storage Productivity Center sensorThe IBM Tivoli Storage Productivity Center sensor discovers storage resources that are related to astorage area network (SAN) and Network Attached Storage (NAS). The sensor extracts data from a TivoliStorage Productivity Center database.

The following resources are examples of what the sensor discovers:

• Storage arrays• Switches• Hosts• Fabrics• Zones• Storage volumes• Array and switch ports• File systems• Disk partitions• NAS-related data

Some of these resources can also be discovered by the host storage sensor (for example, data that isrelated to hosts) and the Fibre Channel switch sensor (for example, data that is related to switches).

Sensor name that is used in the GUI and logsTPCStorageSensor

Prerequisites

Mapping InformationTo get mappings among the Storage resources (Storage disks, volumes, physical hosts, VM machines,SVController as STG virtualizer, FC switches and disks, etc..), the below schema details the prerequisitesat TPC/Spectrum level and TADDM discovery level for each case:

Virtual Server (typically VMware virtual machines) and storage LUNs resources mapping

The relationship can be obtained after both these sensors- HostStorageSensor andTPCStorageServerSensor run successfully.


However, we need to keep into consideration the prerequisites and limitations of both the sensors.

For prerequisites of the Host Storage sensor, please refer to the link below: https://www.ibm.com/support/knowledgecenter/en/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/SensorGuideRef/r_cmdb_sensor_hoststorage.html

For prerequisites of the TPC Storage sensor, please refer to the link below: https://www.ibm.com/support/knowledgecenter/en/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/SensorGuideRef/r_cmdb_sensor_tpcstorage.html

Storage Subsystems and storage LUNs resources mapping

This is an implicit relationship which is shown if the Storage Subsystem is correctly discovered.

Physical Servers and Storage Subsystems resources mapping

This can be obtained from HostStorageSensor. However, we need to keep into consideration theprerequisites and limitations of HostStorageSensor.

Note: The above relationships can be obtained without installing TPC SRA agents on target hosts on TPCdomain of management. Generally, there are some exceptions depending on the TPC Spectrum Controlsource tables. This is because they might not always contain enough minimum information to identify arelated target host (hostname + IP Address data and/or MAC address, etc..) and to always allow TADDM tocorrelate the target hosts to storage subsystem data.

Storage Subsystems Volumes and Target Endpoint Mapping

To get the mapping from Storage Subsystems volume discovered by TADDM (through the TPC Storagesensor) to the endpoint target servers, TPC will need the TPC SRA agents installed on targets hostsaccessing those volumes, since TADDM needs at least the MAC address with the hostname of the targethost to display it as accessing specific volumes. Other alternative is using HostStorageSensor for each ofthe target hosts to store and display the mapping information.

Model objects with associated attributesThe IBM Tivoli Storage Productivity Center sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about storage resources that are storedin Tivoli Storage Productivity Center database.



dev.Controller

• Name• Parent

dev.DiskDrive

• DiskSize• Model• Name• Parent• SerialNumber• Type• Vendor


https://www.ibm.com/support/knowledgecenter/en/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/SensorGuideRef/r_cmdb_sensor_hoststorage.html



https://www.ibm.com/support/knowledgecenter/en/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/SensorGuideRef/r_cmdb_sensor_tpcstorage.html



dev.DiskPartition

• Capacity• Name• Parent• PartitionType• RealizedBy

dev.FCPort

• Label• Parent• PermanentAddress• PortNumber• PortType• Speed

dev.FCVolume

• Capacity• FCPLun• Name• Parent• Type• PortWWN• HostPaths• BasedOn

dev.RealizesExtent


dev.SCSIPath

• ArrayVolume• HostEndPoint• LUN• Parent• Volume


• WorldWideName

dev.TapeDrive

• Label• Type• WorldWideName

net.IpAddress



net.IpInterface




storage.Fabric

• Fcswitch• Label• Name• SourceToken• Virtual• ZoneSets• Zones

storage.FCSwitch

• FCPorts• FCSwitchStatus• Fcport• ManagementURL• Manufacturer• Model• Name• ROMVersion• SerialNumber• Type• WorldWideName• IpInterfaces

storage.StoragePool

• AnsiT10Id• Capacity• Label• Members• Raid Level• RemainingManagedSpace• StorageSubSystem• TotalAvailableSpace• TotalManagedSpace


• AllocatedCapacity• AnsiT10Id• AvailabilityState


• AvailableCapacity• CacheSize• FCPorts• Fqdn• IpInterfaces• IsNetworkAttached• Manufacturer• Members• MemorySize• Model• NumCPUs• ROMVersion• SerialNumber• StoragePools• Type• VolumeGroupCapacity• VolumeGroupFreeSpace


• BlockSize• Capacity• FreeSpace• Name• Parent• RealizedBy• RedundancyMethod• SourceToken• Type• Virtual• Paths

storage.TapeLibrary

• AnsiT10Id• Description• Devices• Manufacturer• Model• ROMVersion• SerialNumber• TapeMediaChangers• Type

storage.TapeMediaChanger

• Caption• Description• Fqdn


• Label• ROMVersion• Type• WorldWideName

storage.Zone

• Active• Description• Name• Parent

storage.ZoneSet

• Active• Label• Name• Parent• Zones

Multiple operating systems:

sys.aix.Aixsys.hpux.HpUxsys.linux.Linuxsys.netware.Netwaresys.OperatingSystemsys.sun.Solarissys.vmware.VmwareESXsys.windows.WindowsOperatingSystem


• FQDN• OSConfidence• OSName• OSVersion• Parent• SoftwareComponents• SystemGuid

Multiple Computer Environments:

sys.aix.AixUnitaryComputerSystemsys.ComputerSystemsys.hpux.HpUxUnitaryComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.SunSPARCUnitaryComputerSystemsys.vmware.VmwareUnitaryComputerSystemsys.windows.WindowsComputerSystem


• CPUSpeed• CPUType• Devices


• FCPorts• FileSystems• Fqdn• IpInterfaces• Manufacturer• MemorySize• Model• NumCPUs• OSInstalled• OSRunning• SerialNumber• Signature• Type• Name• UUID• MacAddress• VMID

sys.FileSystemExport

• Name• Parent

sys.FileSystemService

• Exports• Host• Name

sys.NFSExport

• Name• Parent

sys.NFSService


Multiple file systems:

sys.LocalFileSystemsys.sun.SolarisFileSystemsys.unix.UnixFileSystemsys.windows.WindowsFileSystem


• AvailableInodes• AvailableSpace• Capacity• MountPoint• Parent


• StorageExtent• TotalInodes• Type

sys.SMBExport

• Name• Parent• Path• Type

sys.SMBService



• Name• Parent• SoftwareVersion


Configuring the Tivoli Storage Productivity Center properties fileThe Tivoli Storage Productivity Center sensor uses SQL queries to extract data from the Tivoli StorageProductivity Center database. The SQL queries are defined in the tpc.config file and the execution ofthese queries is controlled by the properties defined in tpc.properties file.

The tpc.config and the tpc.properties are located in: COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.srm.tpc_xxx, where xxx is the sensor plugin version.

The sensor uses the following entries in the tpc.properties file to determine which queries to run:

com.ibm.cdb.discover.app.srm.tpc.sensor.ArrayQueriesThis 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.app.srm.tpc.sensor.HostQueriesThis 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,HOST_SCSI_AGENT_LESS.HOST_SCSI_PATH query

This query is used to create an end-to-end storage mapping from FC volumes on a host to thevolumes on a storage array. This query is enabled by default. Depending on how large the storageenvironment 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_PATHquery only occasionally. To disable this query, do not include the HOST_SCSI_PATH in theproperty: com.ibm.cdb.discover.app.srm.tpc.sensor.HostQueries.For more information about editing the property, see “Out-of-memory error whenHOST_SCSI_PATH or HOST_SCSI_AGENT_LESS query is enabled” on page 406.

HOST_SCSI_AGENT_LESS queryThis query is used to create an end-to-end storage mapping from FC volumes on a host to thevolumes on a storage array, when TPC SRA agents are not deployed to the endpoints. This query is


enabled by default. Depending on how large the storage environment is, running this query canincrease the discovery time of the sensor significantly. Hence, when discovering large storageenvironments, it is better to enable the HOST_SCSI_PATH query only occasionally. To disable thisquery, do not include the HOST_SCSI_PATH in the property:com.ibm.cdb.discover.app.srm.tpc.sensor.HostQueries.For more information about editing the property, see “Out-of-memory error whenHOST_SCSI_PATH or HOST_SCSI_AGENT_LESS query is enabled” on page 406.

The following example shows thecom.ibm.cdb.discover.app.srm.tpc.sensor.HostQueries property with theHOST_SCSI_PATH and HOST_SCSI_AGENT_LESS queries disabled:com.ibm.cdb.discover.app.srm.tpc.sensor.HostQueries=HOST,HOST_PORT,HOST_DEVICE_GROUP,HOST_DEVICE,HOST_DEVICE_PARTITION,HOST_DEVICE_PARTITION_DEVICE,HOST_FS,HOST_FS_EXPORT,HOST_AGENT.

com.ibm.cdb.discover.app.srm.tpc.sensor.FabricQueriesThis property is related to fabric resources. By default, the following queries are enabled:FABRIC,ZONE_SET,ZONE.

com.ibm.cdb.discover.app.srm.tpc.sensor.SwitchQueriesThis property is related to switch resources. By default, the following queries are enabled:SWITCH,SWITCH_PORT.

com.ibm.cdb.discover.app.srm.tpc.sensor.NASQueriesThis 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.app.srm.tpc.sensor.TapeQueriesThis property is related to TAPE resources. By default, the following queries are enabled:TAPE_LIBRARY,TAPE_MEDIA_CHANGER,TAPE_DRIVE.

com.ibm.cdb.discover.app.srm.tpc.sensor.SummaryQueriesThis property is related to SUMMARY resources. By default, the following query is enabled:PORT_CONNECTIVITY.

The following properties are used to control the discovery of certain types of computer systems by theIBM Tivoli Storage Productivity Center sensor:com.ibm.cdb.discover.app.srm.tpc.sensor.ignoreAixCompSys=true

This property determines whether the IBM Tivoli Storage Productivity Center sensor discoverscomputer systems on AIX operating systems or not. By default, it is set to true which means that thesensor does not discover computer systems on AIX operating systems.

com.ibm.cdb.discover.app.srm.tpc.sensor.IgnoreCSWithoutMacaddr=trueThis property determines whether the IBM Tivoli Storage Productivity Center sensor discoverscomputer systems without a MAC address. By default, it is set to true which means that the sensordoes not discover computer systems without a MAC address.

The sensor uses the following entries in the collation.properties when HOST_SCSI_PATH orHOST_SCSI_AGENT_LESS query is enabled.

com.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_PATH.maxrowsThis property specifies the maximum number of rows that the sensor processes, when theHOST_SCSI_PATH query is enabled.The default value is 20000.If the HOST_SCSI_PATH query causes out-of-memory exceptions, decrease the default value. If youwant to collect all the paths in one discovery run, depending on the storage environment, increase thedefault value.

com.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_AGENT_LESS.maxrowsThis property specifies the maximum number of rows that the sensor processes, when theHOST_SCSI_AGENT_LESS query is enabled.The default value is 20000.


If the HOST_SCSI_PATH query causes out-of-memory exceptions, decrease the default value. If youwant to collect all the paths in one discovery run, depending on the storage environment, increase thedefault value.

Configuring the discovery profileThe TPCStorageSensor is enabled by default in the discovery profile.

Create a new profile to modify the following attributes:discoverHosts

The default value for the discoverHosts attribute is true. The sensor discovers host-related data, forexample, ComputerSystem, disks, FC ports, FC volumes, storage volumes, disk partitions, local filesystems, and file system services.If the value is false, host-related data is not discovered by the sensor.

discoverSwitchThe default value for the discoverSwitch attribute is true. The sensor discovers switch related data,for example, switch, switch ports, and FC ports.If the value is false, switch related data is not discovered by the sensor.

restrictByScopeThe default value for the restrictByScope attribute is false. The sensor discovers all the hosts thatthe Tivoli Storage Productivity Center server has already discovered.If the value is true, the sensor discovers the hosts within the discovery scope range of the sensor.

discoverManagedDisksThe default value for the discoverManagedDisks attribute is false.If the value is true, the sensor discovers Managed Disks for SVC (storage virtualization layer) withtheir relationships to the back-end storage.

Note: If you set this attribute to true, the time of discovery and storing of the IBM® Tivoli® StorageProductivity Center sensor is longer, because more data is discovered.

The Host storage sensor and the Fibre Channel switch sensor also discover data related to hosts andswitches. When discoverHosts and discoverSwitch are enabled, consider disabling the Host storagesensor and the Fibre Channel switch sensor to prevent resources being discovered twice.



1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM must use for authentication to

the Tivoli Storage Productivity Center server.3. Select Database as the Component Type and DB2 as the Vendor.4. Specify the access information (user name and password) that TADDM must use for authentication to

the Tivoli Storage Productivity Center database.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM Tivoli Storage Productivity Center sensorand presents solutions for those problems.

Problems connecting to the Tivoli Storage Productivity Center database causesensor failureProblem

The sensor fails due to problems connecting to the Tivoli Storage Productivity Center database.


SolutionVerify that the DB2 credentials of the Tivoli Storage Productivity Center database have been entered.

Host computers are not discoveredProblem

Host computers are not discovered.Solution

The sensor only discovers host systems that are managed by the Tivoli Storage Productivity Centeragent. In addition, verify that the attribute discoverHosts is true for the sensor.

Discovery takes a long time to runProblem

The discovery takes a long time to run.Solution

If the attribute discoverHosts is true, check if the HostStorageSensor sensor is enabled and disableit. If both sensors are enabled, some of the storages resources are discovered twice.

If the attribute discoverSwitch is true, check if the FCSwitchSensor sensor is enabled and disableit. If both sensors are enabled, some of the storages resources are discovered twice.

This problem can also happen if some of the queries that are enabled, generate a large volume ofdata. For example, some of the queries that can generate large volumes of data are: ARRAY_VOLUME,HOST_SCSI_PATH, and SWITCH_PORT. By default, these queries are enabled.

Computer systems are not reconciledProblem

Computer systems discovered by the TPCStorageSensor do not reconcile with the same computersystems discovered by the computer system sensors.

Solution

Computer systems in a storage environment can be physically partitioned or virtualized. If thesesystems are discovered by the TPCStorageSensor, and also by a computer system sensor, the two setsof discovered resources are not reconciled with each other. For example:

• Logical partitions (LPARs) on pSystems discovered by TPCStorageSensor andAixComputerSystemSensor

• Virtual I/O Server (VIOS) discovered by TPCStorageSensor and HMC sensor• Node partitions (NPARs) on HP systems discovered by TPCStorageSensor and

HpUxComputerSystemSensor• 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 theduplicate computer systems and merge them manually.

Out-of-memory error when HOST_SCSI_PATH or HOST_SCSI_AGENT_LESS query isenabledProblem

Depending on the storage environment, the HOST_SCSI_PATH and HOST_SCSI_AGENT_LESSqueries can return a large result set, which might lead to an out-of-memory error.

SolutionThe sensor caps the number of rows it processes for the HOST_SCSI_PATH andHOST_SCSI_AGENT_LESS queries to a default value of 20,000 in order to prevent out-of-memoryerrors. The value is based on:


• Default heap size of the discover JVM (which is 1024 MB)• Default agent timeout value (which is 600000 ms)

In addition, you can configure the sensor to prevent out-of-memory messages, when theHOST_SCSI_PATH or HOST_SCSI_AGENT_LESS query is enabled by using one of the followingmethods:Modify the default number of rows processed by the sensor

Edit the COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.srm.tpc_7.2.0/tpc.properties file and add thefollowing property:

com.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_PATH.maxrows=Xcom.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_AGENT_LESS.maxrows=X

where X is the maximum number of rows the sensor processes for this query.

If this value is greater than 20,000:

• Increase the heap size allocated for the Discover JVM. Edit the $COLLATION_HOME/etc/collation.properties and change the com.collation.Discover.jvmargs.ibmproperty.

For example, to set the heap size to 1824 MB, add the following line:

com.collation.Discover.jvmargs.ibm=-Xdisableexplicitgc -Xmx1824m

• 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 ofmilliseconds 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.• Restart TADDM.

Restrict the scope of storage arrays and Computer systems discoveredThe number of rows returned by the HOST_SCSI_PATH and HOST_SCSI_AGENT_LESS queriescan 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 thatcontains the Tivoli Storage Productivity Center server to be discovered. Include the IPaddress, 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 thesame scope set as the Tivoli Storage Productivity Center server for the discovery. Thesevalues 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-IP-PORT.log(.N) to see the number of SCSI paths that exist per storagearray IP address and per host IP address. The following text is an example of the contents of thelog file:

SCSI PATH statistics by host ip address :ip#1/4 with ipAddress 10.3.41.230 has 160 valid scsi pathsip#2/4 with ipAddress 10.3.41.289 has 527 valid scsi pathsip#3/4 with ipAddress 10.3.43.19 has 108 valid scsi pathsip#4/4 with ipAddress 10.3.42.211 has 160 valid scsi paths

SCSI PATH statistics by array ip address:ip#1/2 with ipAddress 10.0.15.201 has 693 valid scsi pathsip#2/2 with ipAddress 10.0.17.2 has 736 valid scsi paths

Run a discovery with the Tivoli Storage Productivity Center server in a scope of its ownTo get the complete result set of the HOST_SCSI_PATH and HOST_SCSI_AGENT_LESS queriesand prevent out-of-memory errors:

1. Create a Scope Set containing only the Tivoli Storage Productivity Center server (with no othertargets).

2. Create a discovery profile with only the TPCStorageSensor and its dependent sensorsenabled.

3. Start the discovery of the scope set containing the Tivoli Storage Productivity Center serverusing the new profile.

The sensor does not discover any objects due to DNS lookup problemsProblem

The IBM Tivoli Storage Productivity Center sensor finishes with no objects discovered and thefollowing warning is issued:

CTJTD0952W None of the DB2 access list entries are able to connect to the TPC database at URL: jdbc:db2://<host>:<port>/<database>.

SolutionIf <host>, which is read from the data/config/server.config file on your discovery target, is anFQDN or a host name (not a plain IP address), TADDM must be able to resolve it. Configure your DNSin such a way that the nslookup <host> command executed on your TADDM discovery server returnsa resolved IP.

NetApp sensorThe NetApp sensor discovers storage resources that are related to network-attached storage (NAS) byextracting the data from Data ONTAP operating system with the SNMP protocol.

The sensor discovers such storage resources as storage filers, clusters, disk volumes, FC ports, physicaldisk drives, aggregates (represented as storage pools), NFS and SMB Services.

NetApp discovery is run by CustomMib2ComputerSystem that calls extension scripts. Additionally, theSnap Drive sensor is used on the host side to discover defined iSCSI disks. When data is discovered fromboth sources and it matches, a relationship between the host and array is created.

Object identifiers (OIDs)The sensor uses the following high-level OIDs to retrieve the attributes:

• General Information: .1.3.6.1.4.1.789.1.1• Virtual Filers: .1.3.6.1.4.1.789.1.16• Volumes: .1.3.6.1.4.1.789.1.5.8.1• Disk Drives: .1.3.6.1.4.1.789.1.6.10.1


• Spare Disk Drives: .1.3.6.1.4.1.789.1.6.3.1• Cluster Disk Drives: .1.3.6.1.4.1.789.1.6.2.1• Qtree's : .1.3.6.1.4.1.789.1.5.10.1• Clusters: .1.3.6.1.4.1.789.1.25.1• Nodes: .1.3.6.1.4.1.789.1.25.2.1• Storage Pools: .1.3.6.1.4.1.789.1.5.11.1• FC Cards: .1.3.6.1.4.1.789.1.17.17.1.1


• dev.StorageVolume• dev.DiskDrive• dev.FCPort• net.BindAddress• net.IpInterface• net.IpAddress• net.Fqdn• sys.NFSExport• sys.SMBExport• sys.function.StorageSubSystemFunction• sys.ComputerSystemCluster• sys.NFSSAP• sys.SMBSAP• sys.NFSService• sys.SMBService• storage.StorageSubSystem• storage.StoragePool


For SNMP V2 discovery, enter the correct Community String into the access list. You can use the NetworkTemplate (SNMP) Component Type in the Access List window in the Discovery Management Console.

Snap Drive sensorThe Snap Drive sensor discovers storage resources that are related to NetApp SnapDrive software forWindows.

The sensor discovers such storage resources as file system, SCSI Volumes, Host Bus Adaptors and SCSIProtocol Endpoints.

This sensor is a part of the NetApp storage resources discovery. It is required for discovering storageresources like iSCSI on Windows system. Additionally, it provides data to create a relationship with anarray.

Sensor name that is used in the GUI and logsSnapDriveSensor


Security issuesThe user account for discovering Computer Systems is also used for running SnapDrive commands.

The sensor uses the following commands:

• sdcli disk list• iscsicli listpersistenttargets• sdcli iscsi_target list -f <target IP>• sdcli sysconfig list


• dev.SCSIVolume• dev.StorageVolume• dev.BasedOnExtent• dev.SCSIProtocolEndPoint• dev.SCSIPath• storage.HostBusAdaptor• sys.LocalFileSystem


The Snap Drive sensor can be run by using the ComputerSystem access credentials that are used todiscover the client.

Storage sensorThe storage sensor discovers the storage that is attached to a computer system.

The following resources are examples of what the sensor discovers:

• Disks• Partitions• Logical volumes• Physical volumes• File systems

Sensor name that is used in the GUI and logsStorageSensor

PrerequisitesFor 64-bit Linux targets

The 32-bit glibc library is required

LimitationsAccess to the /dev/dsk directory is not available on Solaris local or branded zone target systems.Therefore, not all storage information is retrieved.

When you discover storage attached to a target computer using the host storage sensor, do not carry out adiscovery on the same system using this sensor.


The sensor does not discover the ZFS file systems on the Solaris target systems.


• dev.BasedOnExtent• dev.ControlledBy• dev.Controller• dev.DiskDrive• dev.DiskPartition• dev.FCVolume• dev.RealizesExtent• dev.SCSIVolume• dev.StorageExtent• dev.StorageVolume• sys.NFSFileSystem• sys.unix.UnixFileSystem• sys.LocalFileSystem









The following TADDM server properties specify operating system commands that TADDM uses to retrievestorage information:

• com.collation.platform.os.command.lvm.lvdisplay• com.collation.platform.os.command.lvm.vgdisplay• com.collation.platform.os.command.lvm.pvdisplay• com.collation.platform.os.command.lputil.SunOS

These commands require elevated privilege to run on the target system, and they must be configured touse the sudo command.



Troubleshooting the sensorThis topic describes common problems that occur with the Storage sensor and presents solutions forthose problems.

General problemsDetermine whether information is missing, and identify any command failures due to permissions deniederrors. Verify that commands that require privilege escalation are properly configured. See Configuring thecollation.properties file entries for details.

SVC Storage sensorThe SVC Storage sensor discovers storage resources that are related to SAN (Storage Area Network). Thesensor extracts data from IBM Storage Volume Controller.

The storage resources that are discovered by the SVC Storage sensor include storage array, storagevolumes, FC ports, storage pools and disk drives. The sensor uses the SSH connection to retrieve suchdata.

The SVC Storage sensor discovers world wide port name (WWPN) of the hosts for creating relationship tohost volumes, which requires HostStorageSensor to run on hosts.

It is not advisable to run SVC Storage sensor along with TPC sensor for the same endpoint. It can lead tominor differences in the discovered data like RAID or SCSI Paths, which generates additional entries inchange history.

You can use SVC Storage sensor to discover configuration details of IBM Storwize® v7000storage enclosed in the IBM PureFlex System chassis. See “IBM BladeCenter SNMP sensor” on page 274.

The SVC Storage sensor is enabled by default in the Level 2 and Level 3 discovery profile.

Sensor name used in the GUI and logsSVCStorageSensor

LimitationsThe sensor does not discover Raid Level attribute for Storage Pools and Storage Volume objects becausethe attribute is discovered by TPCStorageSensor for the same objects.

Model objects with associated attributesThe SVC Storage sensor creates model objects with associated attributes. The attributes indicate the typeof information that the sensor collects about storage resources that are stored in SVC.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.dev.DiskDrive

• AdminState• AnsiT10Id• DiskSize• Name• Parent• Status

dev.FCPort

• Parent


• PermanentAddress• PortNumber• PortType• Speed

net.IpAddress


net.IpInterface


storage.StoragePool

• AdminState• AnsiT10Id• Capacity• Label• StorageSubSystem• TotalAvailableSpace


• AllocatedCapacity• AvailabilityState• AvailableCapacity• FCPorts• Fqdn• Manufacturer• Members• Model• ROMVersion• SerialNumber• StoragePools• Type• VolumeGroupCapacity• VolumeGroupFreeSpace


• AdminState• BlockSize• Capacity• DeviceID• IeeeUniqueVolumeName• IOGroup• ManagedSystemName• Name• Parent


• Paths• RedundancyMethod

dev.SCSIPath

• arrayVolume• HostEndPoint• LUN• Parent

physpkg.PhysicalFrame

• AdminState• Label• Manufacturer• Model• Name• Parent• PhysicalPackage• RelativePosition

sys.CPU

• CPUSpeed• IdentifyingNumber• Manufacturer• Parent• VersionString

sys.OperatingSystem

• Name• OSName• Parent


The SVC Storage sensor requires the Computer System credentials of the SVC sensor to run a successfuldiscovery.

The users created on SVC must have a monitor role assigned to run discoveries. The role enables them torun commands like lssystem, lsmdisk, lsmdiskgrp, lsportfc, lsvdisk, lsnode, lsnodevpd,lsnodecanister, lsenclosure, lsvdiskhostmap, or lsfabric.

Veritas Storage Foundation sensorThe Veritas Storage Foundation sensor discovers Veritas Storage Foundation systems.

The Veritas Storage Foundation sensor combines the following principal components and provides asolution for online storage management:

• VERITAS Volume Manager• VERITAS File System


Physical disks are grouped into logical volumes to improve disk utilization and reduce wasted space.VERITAS Volume Manager allows administrators to work with logical names (volumes) rather thanthrough direct access to physical devices.

The VERITAS File System also provides an enterprise journaling file system increasing performance andreliability.

The Veritas Storage Foundation sensor is responsible for discovering the following general VolumeManager configurations:

• Version• Installation directory• 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 layoutversion is collected.

Sensor name that is used in the GUI and logsVeritasStorageSensor

Security issuesThe default user to discover Computer System is used.

LimitationsThe licenses are not supported. There are no application descriptors.


• app.ConfigFile• app.SoftwareInstallation• dev.MediaAccessDevice• dev.veritas.VeritasDiskGroup• dev.veritas.VeritasPlex• dev.veritas.VeritasSubdisk• dev.veritas.VeritasVMDisk• dev.veritas.VeritasVolume• sys.LocalFileSystem• sys.veritasVeritasStorageService


The following properties may require elevated privilege.

• com.collation.discover.agent.command.vxdisk=vxdisk• com.collation.discover.agent.command.vxdg=vxdg• com.collation.discover.agent.command.vxprint=vxprint• com.collation.discover.agent.command.vxupgrade=vxupgrade• com.collation.discover.agent.command.vxdf=df


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

The sensor fails with a timeout error on a Windows platformProblem

The Veritas Storage Foundation sensor fails with a timeout error on a Windows platformSolution

In the configuration file, change the liteDiscoveryMode to true if the sensor times out on aWindows platform. The following example shows the attributes within a predefined configuration file:

<results xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <VeritasStorageAgentConfiguration xsi:type="coll:com.collation.platform.model.discovery.agent. VeritasStorageAgentConfiguration"> <enabled>true</enabled> <familyName>DiscoverSensor</familyName> <name>VeritasStorageSensor</name> <seedClassName>com.collation.discover.seed.app.vsf.VeritasSFSeed </seedClassName> <agentClassName>com.collation.discover.agent.app.vsf.VeritasSFAgent </agentClassName> <liteDiscoveryMode>false</liteDiscoveryMode> </VeritasStorageAgentConfiguration></results>

XIV Storage sensorThe XIVStorageSensor discovers storage resources related to SAN (Storage Area Network) by extractingdata from IBM XIV Storage System.

The storage resources discovered by the XIVStorageSensor include storage array, storage volumes, FCports, storage pools and disk drives. The sensor uses XCLI connection to retrieve the data.

The XIVStorageSensor discovers world wide port name (WWPN) of the hosts for creating relationship tohost volumes, which requires HostStorageSensor to run on hosts.

The XIVStorageSensor is enabled by default in the Level 2 and Level 3 discovery profile.

Sensor name used in the GUI and logsXIVStorageSensor

LimitationsSensor does not discover FC Port Type because it is discovered by TPCStorageSensor for the sameobjects.

Sensor setup requirementsYou must have XCLI application installed on the host. It must be able to reach XIV Storage Systemthrough XCLI native protocol. Configure IP address and path of the host, where the XCLI application isinstalled.

Requirement: XIV Storage System version 4.5 is required.

XIV endpoint might not have SSH enabled and, as a result, Ping sensor returns no objects. In such case,create a new profile and enable the following platform property:

com.collation.pingagent.ports=7778,22,135




The XIVStorageSensor requires the following credentials to run a successful discovery:

• XIVStorage credentials of the XIV Storage System (users with read only permission).• Computer System credentials of the host, where XCLI application is installed.


When the SSH protocol is not available, set the following property in the collation.properties file:

com.collation.pingagent.ports=port_numbers

Model objects with associated attributesThe XIV storage sensor creates model objects with associated attributes. The attributes indicate the typeof information that the sensor collects about storage resources that are stored in XIV.

The sensor creates the following model objects. The attributes that are associated with each model objectare shown below the model object name.dev.DiskDrive

• Model• Name• Parent• Revision• SerialNumber• Status• Type• Vendor

dev.FCPort

• AdminState• Label• Parent• PermanentAddress• PortNumber• PortType• Speed• Status

dev.SCSIPath

• arrayVolume• HostEndPoint• LUN• Parent


net.IpAddress


net.IpInterface


physpkg.PhysicalPackage

• FWRevision• Manufacturer• Model• Name• Parent• PartNumber• RelativePosition• SerialNumber

storage.StoragePool

• AdminState• AnsiT10Id• Capacity• Label• Name• RaidLevel• StorageSubSystem• TotalAvailableSpace


• AnsiT10Id• AvailabilityState• FCPorts• Fqdn• Manufacturer• Members• Model• SerialNumber• StoragePools• SystemId• Type


• BlockSize• Capacity• ManagedSystemName• Name• Parent


• Paths• RedundancyMethod• Type• Virtual

Troubleshooting the sensorThis topic describes common problems that occur with the XIV Storage sensor and presents solutions forthose problems.

Running XCLI commands takes a long timeProblem

Note: The following problem does not apply to XIV Storage System version 4.5 and later.

XCLI is required for XIVStorageSensor to successfully discover XIV. When both TADDM server andXCLI are installed on the Windows operating system, running each XCLI commands might last morethan 2 minutes.

SolutionTo solve the problem, go to the XIVGUI\properties directory, open the xiv-constants.properties file, and change the value of the following property from the default one to0:

xcliServerTimeout


Notices

This information was developed for products and services offered in the U.S.A. IBM may not offer theproducts, services, or features discussed in this document in other countries. Consult your local IBMrepresentative for information on the products and services currently available in your area. Any referenceto 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 notinfringe any IBM intellectual property right may be used instead. However, it is the user's responsibility toevaluate 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 thisdocument. The furnishing of this document does not give you any license to these patents. You can sendlicense inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual PropertyDepartment in your country or send inquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.1623-14, Shimotsuruma, Yamato-shiKanagawa 242-8502 Japan

The following paragraph does not apply to the United Kingdom or any other country where suchprovisions 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 APARTICULAR 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 periodicallymade 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 thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not inany manner serve as an endorsement of those Web sites. The materials at those Web sites are not part ofthe materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate withoutincurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose of enabling: (i) theexchange of information between independently created programs and other programs (including thisone) and (ii) the mutual use of the information which has been exchanged, should contact:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758 U.S.A.

© Copyright IBM Corp. 2008, 2020 421

Such information may be available, subject to appropriate terms and conditions, including in some casespayment of a fee.

The licensed program described in this document and all licensed material available for it are provided byIBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or anyequivalent agreement between us.

Any performance data contained herein was determined in a controlled environment. Therefore, theresults obtained in other operating environments may vary significantly. Some measurements may havebeen made on development-level systems and there is no guarantee that these measurements will be thesame on generally available systems. Furthermore, some measurement may have been estimatedthrough extrapolation. Actual results may vary. Users of this document should verify the applicable datafor their specific environment.

Information concerning non-IBM products was obtained from the suppliers of those products, theirpublished announcements or other publicly available sources. IBM has not tested those products andcannot confirm the accuracy of performance, compatibility or any other claims related to non-IBMproducts. Questions on the capabilities of non-IBM products should be addressed to the suppliers ofthose products.

All statements regarding IBM's future direction or intent are subject to change or withdrawal withoutnotice, and represent goals and objectives only.

This information contains examples of data and reports used in daily business operations. To illustratethem as completely as possible, the examples include the names of individuals, companies, brands, andproducts. All of these names are fictitious and any similarity to the names and addresses used by anactual business enterprise is entirely coincidental.

If you are viewing this information in softcopy form, the photographs and color illustrations might not bedisplayed.

TrademarksIBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International BusinessMachines Corp., registered in many jurisdictions worldwide. Other product and service names might betrademarks 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.

Itanium is a trademark or registered trademark of Intel Corporation or its subsidiaries in the United Statesand other countries.

Java and all Java-based trademarks and logos are trademarks or registered trademarks ofOracle 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, orboth.

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.


http://www.ibm.com/legal/copytrade.shtml