Troubleshooting the sensor

Problem with WMI

Problem

Windows Management Instrumentation (WMI) fails on the system that is to be discovered, which causes discovery to fail.

Solution

Restarting WMI might correct the problem. Use the following commands to restart WMI:

net stop winmgmt
net start winmgmt

If restarting WMI does not correct the problem, use the Microsoft utilities to troubleshoot WMI problems. Refer to the link https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-troubleshooting for more details.

WMIDiag

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

Scriptomatic

The Scriptomatic utility can be used to generate WMI queries that are similar to those used by TADDM. The following WMI classes are some that TADDM queries:

• Win32_Process
• Win32_OperatingSystem
• Win32_WMISetting
• Win32_ComputerSystem

Verify that these classes can be queried using the Scriptomatic utility locally on the target system and remotely from the gateway.

Problem with deployment of WMI provider

Problem

For discovery of Windows systems, TADDM deploys a WMI provider to each target system to enable agentless discovery. Sometimes, problems occur with this deployment.

Solution

The following files comprise the WMI provider and are located on the TADDM server in the $COLLATION_HOME/lib/ms/gateway directory:

TaddmWmi.dll

The WMI provider, which runs TaddmWmi.exe for functionality

TaddmWmi.mof

Specifies the new WMI methods that are provided by the WMI provider (TaddmWmi.dll)

TaddmWmi.exe

Called by the WMI provider (TaddmWmi.dll) to run a command

TaddmWmi.pdb

Contains debugging information for the TaddmWmi.dll file

The TADDM WMI installation provider performs the following tasks:

1. As applicable, copies the files in the preceding list to the following directory on each target system that is in the discovery scope (it uses either the Admin$ or C$ directory to do this): %SystemRoot%\System32\wbem
2. Runs the following commands on each target system:

   On 32-bit Windows operating systems:

   %SystemRoot%\System32\wbem\mofcomp.exe %SystemRoot%\System32\wbem\TaddmWmi.mof
   %SystemRoot%\System32\regsvr32 /s %SystemRoot%\System32\wbem\TaddmWmi.dll

   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 provider manually. To manually install the provider using the TaddmTool program on the Windows gateway, enter the following commands:

1. cd WINDOWS\temp\taddm.nnnn, where nnnn is a string that identifies the TADDM gateway directory. If fixes have been applied to the TADDM server, more than one gateway directory might be present. The identifier string can be found in the DiscoveryManager.log file after the following item: DTADDM_ID=
2. set TADDM_USERNAME=domain\userid
3. set TADDM_PASSWORD=password_for_userid
4. set TADDM_INTERACTIVE=1
5. TaddmTool InstallProvider -AutoDeploy @ipaddress, where ipaddress is the IP address of the target system

WMI access denied errors

Problem

You have WMI access denied errors.

Solution

Refer to Appendix F of the Deployment Guide Series: IBM® Tivoli® Change and Configuration Management Database Configuration Discovery and Tracking v1.1, an IBM Redbooks® publication, at https://www.redbooks.ibm.com/redbooks/pdfs/sg247519.pdf.

WMI process creation errors

Problem

WMI process creation fails with an access error during provider installation. There might be a problem with the Windows Replace a Process Level Token privilege not being granted to the required accounts.

Solution

• This privilege should be granted to the LOCAL SERVICE and NETWORK SERVICE accounts. To verify this, 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 discovery account a member of that group.

The specified network name is no longer available

Problem

If this error occurs, or if there is a problem copying files to the target during provider installation, there might be a problem connecting to the SMB (file sharing) service on the target machine.

Solution

Complete the following steps:

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 window and running the following command:

   telnet <target machine name> 445 

3. If it is refused, repeat step b using port 139. If both fail, you have 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 SMB service.

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

Problem

The slow discovery of Windows 2003 SP1 systems, or applications running on those systems, might be a result of a memory leak in the WMI service.

Solution

Ensure that the following hotfix, available from Microsoft, is installed: http://support.microsoft.com/kb/911262

Windows 2000 systems are not discovered

Problem

If Windows 2000 systems are not discovered, the problem might be because an unsupported version of the netstat program installed on the target system. The netstat program is used to get TCP port information during discovery. Windows 2000 systems use a different version of the netstat program from the one installed on systems running later versions of Windows.

Solution

Ensure 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 is unavailable.

Solution

To discover a Windows target when there is a Local firewall that is enabled, restrict the RPC ports on Windows 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.
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' error

Problem

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 0
java.io.EOFException: SSHSCP1: premature EOF

Solution

To 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 the com.collation.platform.os.scp.command property in the collation.properties file to point 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.exe
   com.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 might affect security. In such case, you must make sure that the used SCP program is FIPS-compliant.