Guide to Troubleshooting ServiceNow Discovery Issues
Overview
While managing ServiceNow Discovery, various issues related to host connectivity, credential verification, and service configurations may arise. Below are some common discovery errors encountered, along with troubleshooting steps to help resolve these issues effectively.
Requirements for the Discovery Scan:
Use Case 1: Host Connectivity Issues:
Issue: The host with IP 10.XX.XX.196 is not reachable (no response to target ports scanned by MID).
Symptoms:
- Discovery reports the host as unreachable or fails to connect.
- Errors related to network timeouts or port unavailability.
Troubleshooting Steps:
- Ping the Target Device from the MID Server:
- Use the following PowerShell script on the MID Server to determine the status of specific ports:
To check which port is open:
# Define the ports and their associated services
$ports = @{
'WMI' = 135
'SNMP (UDP)' = 161
'SNMP Trap (UDP)' = 162
'SSH' = 22
'HTTP' = 80
'WINS' = 42
'DNS' = 53
'SLP' = 427
'WBEM (HTTP)' = 5988
'WBEM (HTTPS)' = 5989
'WinRM (HTTP)' = 5985
'WinRM (HTTPS)' = 5986
'ESXi (confirm specific port)' = 443 # Example for ESXi management port, change if needed
}
# Loop through each port and check its status
foreach ($service in $ports.Keys) {
$port = $ports[$service]
$result = Test-NetConnection -ComputerName 10.XX.XX.196 -Port $port
if ($result.TcpTestSucceeded -or $result.UdpTestSucceeded) {
Write-Output "$service on port $port is open"
} else {
Write-Output "$service on port $port is closed"
}
}
Typical Port Numbers:
- WMI: 135
- SNMP (UDP): 161
- SNMP Trap (UDP): 162
- SSH: 22
- HTTP: 80
- WINS: 42
- DNS: 53
- SLP: 427
- WBEM (HTTP): 5988
- WBEM (HTTPS): 5989
- WinRM (HTTP): 5985
- WinRM (HTTPS): 5986
- ESXi (confirm specific port): 443
Use Case 2: Classified but Disabled
Issue: The classification for a specific type of server (e.g., Windows) is disabled.
Symptoms:
- Discovery fails to classify or identify the target correctly.
- Errors indicating that classification is not applied.
Check Windows Classifications:
- Navigate to the Windows Classifications within ServiceNow.
- Ensure that the classifier for Windows servers is enabled. If it is disabled, enable it and re-run the Discovery.
Use Case 3: Credential Verification Issues
Issue: Credentials for WMI, SSH, or SNMP are failing or incorrect.
Symptoms:
- Discovery fails to authenticate or access target systems.
- Error messages indicating credential issues or access denials.
Troubleshooting Steps:
- WMI Credentials:
- Test WMI credentials directly in ServiceNow by navigating to the Credential table and using the "Test Credential" UI action.
- Additionally, run the following PowerShell command from the MID Server using the Windows credentials:
PS C:\> $cred = Get-Credential -UserName "domain \username " -Message "Enter the password for the service account"
>> Get-WmiObject -Class Win32_OperatingSystem -ComputerName "10.XX.XX196" -Credential $cred
If it is successful, it will show the details below:
SSH Credentials:
- Test SSH credentials by navigating to the Credential table in ServiceNow.
- Confirm SSH authentication using an SSH client like PuTTY. For authorization issues, verify command permissions with:.
sudo -l
Ensure the mid.ssh.use_snc parameter is set correctly to avoid client conflicts.
SNMP Credentials:
- Test SNMP configuration using:
snmpwalk -v 2c -c <community_string> <target_ip>
Note that SNMP uses UDP and may time out if credentials or network conditions are incorrect.
Use Case 4: Classified but Couldn't Identify:
Troubleshooting Steps:
- Check the Identification and Reconciliation Engine (IRE) Rule:
- Navigate to the Identification and Reconciliation Engine (IRE) rules within ServiceNow.
- Verify that the IRE rules are correctly configured to handle the type of server or device in question.
- Ensure that the rules are enabled and properly aligned with the classification of the target server.
