Discovery Management Console problems

This information covers common problems that occur with the Discovery Management Console.

General problems

To debug problems in the Discovery Management Console, you might need to put the Discovery Management Console in debug mode. To do this, complete the following steps:
  1. From the command prompt of the computer where the Discovery Management Console is running, enter the javaws command. The Java™ Application Cache Viewer opens.
  2. Click Edit > Preferences. The Java Control Panel window opens.
  3. In the Java Control Panel window, click the Advanced tab.
  4. Expand Java console.
  5. Click Show console.
  6. Restart the Discovery Management Console.

As you navigate the Discovery Management Console, a Java console is shown with messages. Reproduce the problem that you were having. If an error message is shown, copy and paste the message and stack trace into a file for IBM® Support. If no error message is shown (especially if the problem is related to performance), cut and paste the entire console window into a file for IBM Support.

If you cannot access the Discovery Management Console, you can have the Discovery Management Console debug messages copied to a text file. To do this, complete the following steps:
  1. From the command prompt of the computer where the Discovery Management Console is running, enter the javaws command. The Java Application Cache Viewer opens.
  2. Click Edit > Preferences. The Java Control Panel window opens.
  3. In the Java Control Panel window, click the Advanced tab.
  4. Expand Debugging.
  5. Click Enable logging.
  6. Click Enable tracing.
  7. Restart the Discovery Management Console.
On Linux®, Solaris, AIX®, and Linux on System z® operating systems:

The log and trace files must be in the user_home/.java/deployment/log/javaws directory, where user_home is your home directory. An example is /home/cmdbuser/.java/deployment/log/javaws.

On Windows operating systems:

The log and trace files must be in the IBM\Java\Deployment\log directory. Examples are C:\Documents and Settings\Administrator\Application Data\IBM\Java\Deployment\log or C:\java_home\IBM\Java\Deployment\log, where java_home is the directory where the Java runtime environment is installed.

Collect the log and trace files in to a compressed file, and send that file to IBM Support.

A warning CTJTG0034E is displayed each time you start the Discovery Management Console

Problem
Each time that you start the Discovery Management Console, a warning message is displayed, saying that you have an unsupported version of Java runtime environment.
Solution
Complete one of the following procedures:
  • Install the supported Java runtime environment.
  • Fix Pack
3 If you want to use the unsupported Java runtime environment and you do not want the warning to be displayed, go to the collation.properties file, and set the value of the com.ibm.cdb.gui.supportedJRE.warning property to false.

IP addresses that have been assigned to specific subnets as a result of Level 2 or Level 3 discoveries are reassigned to different subnets after running a Level 1 discovery

Problem
In some cases, a Level 2 or Level 3 IP address might be incorrectly reassigned to another subnet when you run the $COLLATION_HOME/bin/adjustL1Networks.sh command after changing the configuration variable in the DefaultNetmask property.
Solution
Run a Level 2 or Level 3 discovery for the reassigned IP addresses to restore them to their correct subnet.

Console stops after running the Clear Topology Data function in DB2

Problem
When running the Clear Topology Data function to remove discovery data from a DB2® database, you receive an error message stating that the transaction log in the DB2 database is full. The Clear Topology Data function then ends in failure, and the Discovery Management Console stops.
Solution
The default value of the DB2 logsecond parameter is not adequate for large transactions. Increase the value of the DB2 logsecond parameter to have DB2 create more temporary transaction logs.

Unreadable characters in a PDF report for non-English languages

Problem
The PDF file generated by the report function of the Discovery Management Console contains unreadable characters for some non-English languages.
If the Discovery Management Console is running in a non-English language, the PDF file that is generated for reports includes the language-dependent font for the operating system on which the TADDM server runs. Sometimes the operating system does not have the appropriate font to display the language-dependent characters
This problem also happens in various languages if the TADDM database has the language-dependent characters discovered from the remote systems.
Solution
Complete the steps listed in either of the following two solutions.
  1. Copy the WorldType font from the TADDM Disc 1 installation DVD to your client machine. If you downloaded TADDM in the zip format, the zip files number 1 and 2 are the equivalent of Disc 1.
    1. Insert the TADDM Disc 1 installation DVD into your client machine.
    2. Copy the following four WorldType font files:
      • /other/tnr_s__b.ttf
      • /other/tnr_j__b.ttf
      • /other/tnr_k__b.ttf
      • /other/tnr_tt_b.ttf
      to the following location:
      • (For Windows) C:\WINNT\Fonts or C:\WINDOWS\Fonts
      • (For UNIX or Macintosh /usr/share/fonts or /usr/lib/X11/fonts
    3. Stop and restart the Discovery Management Console.
  2. Enable the automatic download function of the WorldType font:
    1. Open the $COLLATION_HOME/etc/collation.properties file on the TADDM server computer.
    2. Specify the following parameters and save the collation.properties file:

      com.collation.report.pdf.enableWorldTypeFont=true

    3. Stop and restart the TADDM server.
Note: If this function is enabled, the Discovery Management Console automatically downloads the WorldType font on the first startup. Because the WorldType font is approximately 20-25 megabytes, the first startup of the Discovery Management Console is slower. Once it is downloaded, the font file is cached for the next time the Discovery Management Console is started.

National language characters are not shown properly

Problem
For Windows computer system discovery, if all of the following conditions are true, some national language characters are not shown properly in the Discovery Management Console:
  • The system locale is Arabic.
  • You are in the Discovery Management Console looking at the File System column.
  • You are using the SNMP option for discovery of your Windows computer system.
Solution
For Windows computer system discovery, use the Windows Management Instrumentation (WMI) option.

After a discovery is complete, certain functions can be temporarily unavailable

Problem
For a brief period after a discovery is complete, you might be unable to access certain functions. For example, immediately after a discovery completes you might be unable to open the Access List pane.
Solution
Wait for a few minutes to ensure that all the sensor processes are complete before carrying out the next task.

An icon defined in the Discovery Management Console is displayed differently in the Data Management Portal

Problem
An icon set up in a custom template might be displayed differently when shown in the Discovered Components pane of the Data Management Portal.
Solution
Because the technology used in the Data Management Portal differs from that of the Discovery Management Console, an icon in one user interface (UI) might be displayed differently to the same icon in the other UI. This effect is cosmetic and does not affect the operation of the TADDM deployment.

The default page layout size for printed details is set to letter in the Discovery Management Console

Problem
The default page layout size of the printed details is fixed as 'letter' size. In Japan, letter size is not supported; therefore, the default page layout size must be changed to A4 size.
Solution
You can change the default page layout size from letter to A4 by editing the value parameter in the following property statement:
<property name="printPageLayoutSize" value="letter" /> 
Administrators can change the value parameter in the template.jnlp file. Discovery Management Console users can change the value parameter in the confignia.jnlp file.
To change the default page layout, log in as administrator, and complete the following steps from the discovery server:
  1. Depending on the TADDM version you use, go to the one of the following directories:
    • TADDM 7.3.0: /opt/IBM/cmdb/dist/deploy-tomcat/install/template.jnlp.
    • TADDM 7.3.0.1, and later: /opt/IBM/cmdb/dist/apps/install/template.jnlp.
  2. In the template.jnlp file, change the value letter to A4 for the printPageLayoutSize property:
    <property name="printPageLayoutSize" value="A4" /> 
  3. Stop and restart the Discovery Management Console
  4. Optional: Most users use a page layout size of A4 but you need a page layout size of letter, complete the following steps:
    1. Save the confignia.jnlp locally.
    2. In the confignia.jnlp change the value A4 to letter for the printPageLayoutSize property:
      <property name="printPageLayoutSize" value="letter" /> 
    3. Run the configuration file as shown in the following example:
      • If the confignia.jnlp is associated with Java Web Start, double-click the confignia.jnlp file.
      • If not, enter the following command:
        On Windows operating system:
        JAVA_HOME\bin\javaws.exe 
        SAVED_DIRECTORY\confignia.jnlp 
        On UNIX operating system:
        JAVA_HOME/bin/javaws 
        SAVED_DIRECTORY/confignia.jnlp

        where JAVA_HOME is the directory where the Java runtime environment is installed, and SAVED_DIRECTORY is the directory where confignia.jnlp is saved.

    You can use step 4 without carrying out the preceding steps to change locally the default page layout size parameter in the confignia.jnlp file.

Discovery console stops responding when you try to log on using SSL certificate

Problem
The certificate is generated by using a host name or an IP address and to access TADDM Discovery Console, the same address must be used. When the certificate host name is different, the user is unable to authenticate and the console might stop responding.
Solution
Make sure that you use the same name to access TADDM Discovery Console as the one used for certificate generation.