Docs › Discovery

Troubleshooting Discovery

Last updated 2026-07-14

Troubleshooting Discovery

This guide helps diagnose and resolve common discovery issues.

Reading the Run Log

Every discovery run has a detailed log. Navigate to Discovery → Runs, click on a run, and review the log entries. Key messages to look for:

Log Message	Meaning	Action
`[seed-scan] 254 total, 28 responded, 226 dark`	Seed scan completed — 28 of 254 IPs had at least one open TCP port	Normal. "Dark" hosts have no open ports or are powered off.
`[smart-scan] 192.168.1.10: no recognisable ports`	Host responded but ports don't map to any known connector	Asset created as UNKNOWN_ENDPOINT. Check the Dashboard's Unknown Endpoints table.
`no matching credentials`	Port open but no credential's match pattern covers this IP	Edit the credential and add this IP or CIDR to the match pattern.
`Detected ESXi host — using esxcli commands`	SSH connector detected ESXi and switched to esxcli mode	Normal — ESXi-specific data collection in progress.
`SSH_MSG_DISCONNECT: 2 Too many authentication failures`	ESXi or SSH server locked the account after too many failed attempts	Reset with `pam_tally2 --reset --user root` on ESXi. Use targeted scans for ESXi hosts.
`WinRM pwsh exit=1`	PowerShell Remoting command failed on a Windows host	Check WinRM is enabled, account has permissions, and firewall allows TCP 5985.
`vSphere session create failed: HTTP 503`	VMware REST API service is down on vCenter/ESXi	Restart the VAPI endpoint service on vCenter, or use SSH discovery for ESXi 6.x.

Common Issues & Solutions

VMware ESXi — Account Lockout

ESXi has a strict lockout policy (typically 5 failed attempts per source IP, 15-minute window). This is commonly triggered when a Smart Scan tries multiple credentials against the ESXi host.

Symptoms: SSH_MSG_DISCONNECT: 2 Too many authentication failures or Auth fail

Fix:

SSH into the ESXi host from a machine that is NOT locked out
Run: pam_tally2 --reset --user root
Use a targeted SSH_UNIX scan (not Smart Scan) for ESXi hosts

VMware ESXi — "Auth fail for methods publickey,keyboard-interactive"

ESXi uses keyboard-interactive authentication, not plain password. uControl Insight handles this automatically for SSH_PASSWORD credentials. If you see this error on older builds, update to the latest version.

VMware vCenter — HTTP 503 on REST API

The vCenter REST API depends on the VAPI endpoint service. If it returns 503:

vCenter Appliance (Linux): service-control --start vmware-vapi-endpoint
vCenter on Windows: Start "VMware vAPI Endpoint" in Windows Services
vCenter 6.0: Does not have the REST API. Use SSH discovery for ESXi hosts instead.

Host shows as UNKNOWN_ENDPOINT despite having credentials

Check the credential's match pattern includes this host's IP
Check the priority — lower numbers are tried first
Check the run log for "no matching credentials" vs "authentication failed"

Windows host not discovered (WinRM)

Is WinRM enabled? Test with Test-WSMan -ComputerName hostname
Firewall — Is TCP 5985 open?
Account in "Remote Management Users" or "Administrators"?
LocalAccountTokenFilterPolicy set to 1 for local accounts?
PowerShell Core (pwsh) installed on scanning host?
Run the Windows setup script from Credentials → Discovery Setup Guide

Linux host not discovered (SSH)

SSH server running? Test with ssh user@host
TCP 22 open in firewall?
For key auth: credential type is SSH_KEY, private key in PEM format?
User has a valid login shell?
Test the credential from the Credentials page

Network device not discovered (SNMP)

Seed scan uses community "public" for detection. Full scan uses your configured community string.
SNMP uses UDP 161 — verify with snmpwalk -v2c -c community host
Verify SNMP agent is enabled on the device

Duplicate assets appearing

Identity resolution uses: serial number, virtualization UUID, MAC address, FQDN, IP address. Duplicates occur when the device has no unique identifiers or its IP changed between scans.

Assets showing as PHYSICAL_HOST but should be VM

SSH classifies hosts as PHYSICAL_HOST initially. After the hypervisor scan runs, the normalization pipeline detects the HOSTED_ON relationship and reclassifies them as VM.

Scan is slow

Symptom	Cause	Solution
Seed scan slow	Large CIDR, many dark IPs	Use smaller CIDRs or increase concurrency
Phase 2 slow	Many credential attempts per host	Reduce broad match patterns, use scan hints (automatic)
WinRM slow	PowerShell remoting overhead	Ensure adequate CPU on scanning host, use a local worker

Credential Test

Navigate to sidebar → Credentials, click Test, enter the target IP. Reports success with latency or failure with error message.

Log Files

Location: /opt/tomcat/logs/catalina.out or configured log path
Key prefixes: [seed-scan], [smart-scan], SNMP discovery, WinRM pwsh, SSH discovery, Detected ESXi host, ESXi discovery, Omada connected

Performance Tuning

Setting	Default	Effect
Target concurrency limit	20	Max parallel host scans in Phase 2
Seed scan concurrency	500	Max parallel TCP probes during seed scan
Probe timeout	300ms	TCP connection timeout per port
DB connection pool	50	Increase for 10,000+ asset environments