These properties apply to discovery generally. The TADDM server properties that affect a specific sensor are documented in the TADDM Sensor Reference for the respective sensor.
- This property specifies the maximum number of channels opened simultaneously in the SSH session between the TADDM server and the anchor. If the number of opened channels is too high, the discovery on such anchor might hang, and the sensors included in such scope might time out. In such case, use this property to control the number of opened channels.
- The default value is 50.
- This property specifies whether the external scp command is used to copy
files from remote hosts, usually discovery targets, to the TADDM server. The external
scp command is defined in the
com.collation.platform.os.scp.commandproperty. To enable the usage of external scp command, set this property to true.
- The default value of this property is false.
Note: This property applies only to the SSH sessions that are established with a key-based login (see Configuring for discovery using the Secure Shell (SSH)). In case of authentication with a user name and a password, the internal scp command is used regardless of the
- This property is a scoped property. You can append an IP address or the name of a scope set to
the property. For
- This property specifies the path to the Operating System scp command. It can be used when an internal SSH client fails to send files between the TADDM server and remote hosts, usually discovery targets. You can also use an alternative command but it must have the same syntax as the scp command.
- The example value: /usr/local/bin/scp.
- This property specifies whether logging in with Windows credentials is attempted when SSH session is used. The default value is true.
- You can set the value to false, if there is a risk that during the discovery there are attempts to log in to non-Windows servers with Windows credentials. It can prevent locking out Windows Active Directory accounts.
- This property specifies the descriptions of discovered L2Interfaces that you want to be ignored
during the computer system signature calculation. For example, if you do not want Microsoft Load
Balancer Interface to be used to calculate the signature of a computer system, specify the following
The value of this property is treated as a regular expression. It means that you can add more than one interface description, and you do not need to use any separator such as comma.
com.collation.platform.os.ignoreL2InterfaceDescription=Microsoft Load Balancer Interface
- This property, if set to true, creates placeholder App Servers for undiscovered dependencies.
Note: This property is not included in the collation.properties file by default. You must add it there.
- When you set the value to true for the first time, you must restart TADDM to enable extended attributes for LogicalConnection and SSoftwareServer classes. These extended attributes are necessary for proper functioning of this feature.
- For more information about placeholders, see Configuring for discovery of placeholders.
- This property specifies the type of encoding used during a discovery session. It is especially useful when your target servers use different encoding than the one in the TADDM server.
- The value of this property is the name of the encoding, for example UTF-8. It is not included in the collation.properties file by default, you must add it there.
- You can also add a scope, or an IP address to this property. For
- The default value is true.
This property specifies whether the anchors for the discovered scope are to be deployed during discovery startup.If you set the value to false, the anchors are deployed only if either of the following conditions are met:
- If any IP address from the scope cannot be pinged
- If port 22 cannot be reached on any of the discovered IP addresses
- The default value is false.
This property specifies whether files that a sensor requires are copied when an anchor is deployed (a value of false) or when the sensor that requires the files is about to start (a value of true).
For example, the IBM® WebSphere® sensor has dependencies in the dist/lib/websphere directory. The size of the directory is 130 MB. If the value of this property is false, the dependency data is copied to the target host when the anchor is deployed. If the value is true, the data is copied when the WebSphere sensor is about to be run on the anchor. If no WebSphere sensor is run through the anchor, 130 MB is not sent to the remote host.
- The value is 600000 (in milliseconds),
which is 10 minutes.
This property specifies the timeout for sensors in milliseconds. The default timeout should not be changed. Instead, you can specify the timeout for individual sensors.To override the timeout for a particular sensor, add the following line to the collation.properties file:
Here is an example:
- com.collation.IpNetworkAssignmentAgent.defaultNetmask=ip_start-ip_end/netmask[, ...]
This property defines how IP addresses discovered during a Level 1 discovery are assigned to generated subnets. A Level 1 discovery does not discover subnets. Instead, IpNetwork objects are generated to contain any interfaces that are not associated with an existing subnet discovered during a Level 2 or Level 3 discovery. This configuration property defines which IpNetwork objects are created, and how many nodes each subnet contains. (It also applies to any interface discovered during a Level 2 or Level 3 discovery that for any reason cannot be assigned to a discovered subnet.)
The value for this property consists of a single line containing one or more entries separated by commas. Each entry describes an IP address range in IPv4 dotted decimal format, with a subnet mask specified as an integer in the range of 8 - 31. Discovered interfaces in the specified range are then placed in created subnets that are no larger than the size that is specified by the subnet mask.For example, the following value defines two subnet address ranges with different subnet masks:
The specified address ranges can overlap. If a discovered IP address matches more than one defined range, it is assigned to the first matching subnet as they are listed in the property value.After you create or change this configuration property and restart the TADDM server, any subsequent Level 1 discoveries use the defined subnets. To reassign existing IpInterface objects in the TADDM database, go to the $COLLATION_HOME/bin directory and run one of the following commands:
This script reassigns all IpInterface objects discovered during Level 1 discoveries to the appropriate subnets as described in the configuration property. Any generated IpNetwork object that contains no interfaces is then deleted from the database. After the script is completed, the TADDM interface might show multiple notifications of changed components because of the modified objects. You can clear these notifications by refreshing the window.Note: Before you use this command, make sure that the TADDM server is running, and that no discovery or bulk load operation is currently in progress. This script is not supported on the synchronization server.
- adjustL1Networks.sh (Linux® and UNIX systems)
- adjustL1Networks.bat (Windows systems)
- The default value is 30.
Specifies the number of discoveries for which information is saved in the discovery history in the Data Management Portal and the Discovery Management Console.
To change the default value in a streaming server deployment, enter the new value on the primary storage server.
- Specifies the fully qualified path to the directory where component
application descriptor files for computer systems (hosts) are deployed.
This property is required if you want to add computer systems to business
applications using application descriptors. You can scope this property
to a specific host name or IP address in order to specify a different
location for each host. The following examples show how to specify
the host application descriptor path:
- Linux and UNIX systems:
- Windows systems:
- Linux and UNIX systems:
- Specifies whether to force the gateway to act independently of the anchor. Valid values are true and false. Set the value to true to resolve Cygwin issues when both the gateway and anchor are on the same system. When the value is set to true, an SSH session is used to transfer traffic between the gateway and anchor rather than a local session.
- The default value is false. This property applies to the rediscovery of a configuration item that has already been discovered. The rediscovery functionality is available in the Data Management Portal.Restriction: Rediscovery cannot use the credentials from a custom profile, it uses the credentials from the global list.Note:
To enable rediscovery in a domain server deployment, set the value to true on the domain server.To enable rediscovery in a streaming server deployment, set the value to true on the discovery server and the storage server.
- Rediscovery in a streaming server deployment
- When rediscovery is used in a streaming server deployment, a configuration item can be
discovered by different discovery servers, but only the last discovery server to discover the
configuration item can rediscover that configuration item. Because there are multiple discovery
servers, rediscovery information for a configuration item is overwritten by each discovery
When you enable rediscovery on the discovery server, for each object discovered, additional information about the rediscovery is created.
When you enable rediscovery on the storage server, each object that is discovered is stored with additional information about the rediscovery.
If rediscovery is enabled on the discovery server but disabled on the storage server, information about rediscovery will not be available in the TADDM database. In addition, you must ensure that the same credentials are used for both the discovery server and the storage server.
- The default value is /tmp/taddm.
This property specifies the root path for the IBM Tivoli® Utilization sensor scripts to run on the target system. If this value is not specified the path defined by the com.ibm.cdb.taddm.script.path property is used.
- Specifies the location tag attribute for each configuration item (CI) created on the TADDM server. The location tag attribute, which identifies the location of a CI, is used to support static location tags. Before specifying this tag, you must set the com.ibm.cdb.locationTaggingEnabled value to true.
- The default value is false.Specifies whether location tagging functionality is enabled. Set the value of this property to true to:
- Specify a location tag attribute for each configuration item (CI) created on the TADDM server (static location tags). See the com.ibm.cdb.locationTag property for details.
- Specify a dynamic location tag for configuration items (CIs) created during a single discovery, using the command-line interface (CLI). Dynamic location tags override location tags that already exist (static location tags).
- Specify a dynamic location tag for configuration items (CIs) created when loading data using the bulkload program.
- Specify a location tag value when running a BIRT report to filter the data and report information only about that specified location.
- Create a location tag value for configuration items created during a typology build process.
- Specifies the TADDM server host alias. If this value is not specified the system hostname is used. If the TADDM server cannot resolve the system hostname or it resolves to the localhost then you must specify this property manually.
- The default value is /tmp/taddm.
This property specifies the root path for the sensor scripts to run on the target system. In this location, a subdirectory tree is created using the format: host_alias/discovery_number/sensor_name. The host_alias name is retrieved from the
com.ibm.cdb.taddm.hostproperty. If this property is not specified the system hostname is used. To differentiate between concurrent discoveries on the same discovery server, a number is assigned to the discovery_number directory. The discovery scripts and discovery results are stored using this directory structure.
- This property is used to skip an IP address during the signature
In case of some configurations, the signature for a computer system might result as not unique, which causes problems during the reconciliation with the existing entries in the TADDM database. For example, it can happen when you use virtual machines with virtual network cards that have a valid hardware address and IP address. In such cases, you must exclude the signature calculation and use other naming rules, for example ProductModel, Manufacturer or Serial Number.
For each IP address that you want to be ignored, add the
com.collation.discover.agent.signature.ignore.18.104.22.168=true property, where 22.214.171.124 is the IP address to be ignored.
If you want many IP addresses to be ignored, you can create a discovery scope. Add the
com.collation.discover.agent.signature.ignore.blacklist=trueproperty to the collation.properties file, where blacklist is the discovery scope with all IP addresses to be ignored.