Troubleshooting Discovery

[SAI VENKATESH]

The following actions can be used to troubleshoot discovery and determine the potential root cause.

Run discovery through a different MID Server, as known issues exist where discovery may fail on certain MID Server versions while succeeding on others.

See Troubleshooting a failed Discovery.

General Troubleshooting done from Mid Server to target to check connectivity.

Ping is a basic but effective way to verify network connectivity. From the MID Server host, PowerShell can be used to test reachability for multiple target systems in a single execution.

Option A: Computer Names in the command line 

Test-Connection -ComputerName 192.168.0.2,192.168.0.1,examplehost -Count 1

Option B: Ping computer details from a text file

Test-Connection -ComputerName (Get-Content C:\Data\Computers.txt) -Count 1

Telnet into the port used for the credential test

A successful ping only confirms that the target device is reachable at the network level. Discovery and credential validation also require access to specific service ports used by the underlying communication protocols. If these ports are blocked, discovery will fail even though the device responds to ping.

telnet <ip_address> <port_number>

The following are some of the ports used out of box, however a system administrator could change these ports.

WMI: 135
SSH: 22
VCenter: 443
WBEM: 5989
LDAP: 389

If the telnet test fails, an error message would be displayed, please consult the target device administrator and the network administrator to confirm that:

1. The firewall on the device allows traffic on the port tested by telnet
2. There are no network firewalls blocking traffic from the MID server to the target host on the port tested

Telnet is an application that operates TCP Protocol.  UDP Connection cannot be tested by using Telnet.

Port Connectivity Check 

Depending on the target port for discovery you can do the port connectivity test using the same command, for example Port 22 for Linux/Unix devices or 135 for windows devices 

Test-NetConnection -ComputerName 192.168.0.1 -Port 135  -Count 1

Collecting MID Server Debug logs

Collecting MID Server Debug Logs

To enable debug logging on a MID Server:

1. Navigate to MID Server > Servers.

2. Open the MID Server associated with the failed Discovery or Orchestration activity.

3. In the Configuration Parameters related list, click New.

4. Set Parameter Name to mid.log.level and value to debug.

5. Reproduce the issue.

6. After troubleshooting is complete, reset the value to info to avoid excessive logging.

To collect the MID server logs, follow these steps:

1. On the MID server record click on Grab MID logs.
2. Click on the input records displayed.

Error: Active, couldn't classify: No WMI connection

Validate Credential using RDP

RDP from the MID server to the Remote Windows host to validate the Windows credential. This will validate the credential outside of ServiceNow discovery. This step only validates the credential - because RDP communicates on port 3389 to login to the Remote Windows host while ServiceNow Discovery uses a different range of ports for login and discovery communication.

Windows Credentials

A simple PowerShell WMI query directly from the MID Server to the remote machine can be used to test access and permissions. 

Open a PowerShell command line on the host where the MID server is being used and run the following:

gwmi win32_operatingsystem -computer 192.168.200.14 -credential 'LOCALDOMAIN\mid'

Work with the network team to confirm that the required WMI ports are accessible between the MID Server and the target Windows system.

ServiceNow Discovery relies on WMI for Windows-based discovery. For this communication to succeed, the following connectivity must be available:

• Port 135: Required for the initial WMI connection from the MID Server to the remote Windows host.