Analysing Discovery Problems
When a discovery scan does not return expected results, this page explains how to diagnose the problem using log files, event logs, and the discovery output files.
Prerequisites
- You need access to the Collection Server (usually the application server) to inspect discovery output files
- Administrator or Domain Admin credentials may be needed to read event logs
Common Causes of Discovery Failure
| Symptom | Likely Cause | Action |
|---|---|---|
| No assets discovered at all | Discovery Service not running | Check the Windows Services console on the Collection Server |
| Some machines missing | Credential Pack does not have admin rights on those machines | Verify the Credential Pack or service account has local admin access |
| Discovery runs but no data loads | Data loader did not run after discovery | Run Discover > Load Now manually (see Loading Discovery Data) |
| Discovery very slow | Too many threads or very large subnet | Reduce the thread count in the XDSL script, or split into smaller IP ranges |
| SNMP devices not found | Wrong SNMP version or community string | Check the Credential Pack matches the device's SNMP configuration (see SNMP Discovery) |
Understanding Discovery Output Files
An XDSL discovery script should run error-free provided you are running under Domain Admin credentials on the application server. Any errors are recorded in log files and the Windows Application Event Log on the Collection Server.
Several types of file are written to the Collection Server folder share, typically at PCAnalyser\netdiscover:
| File Extension | Source | Contents |
|---|---|---|
| .PCA | PCAnalyser executable | Hardware and software inventory collected by the lightweight agent running on the target machine's CPU |
| .PCZ | XDSL script executable | DNS information and data from agentless discovery (WMI, Remote Registry, SNMP) |
| .PCV | VBScript discovery | Output from custom VBScripts included in the discovery template (e.g., VMware discovery) |
| .PCS | SQL Server Analyser | SQL Server instance, database, and file information collected from database servers |
Inspecting Discovery Files
- Navigate to the PCAnalyser share on the Collection Server (typically
\\<servername>\pcanalyser\netdiscover) - Look for files with the target computer's name -- if no file exists, discovery did not reach that machine
- PCA files are encrypted. Use the PCA File Viewer application (found in Start > xAssets Collection Server on the Collection Server) to view their contents
- PCZ and PCV files are text-based and can be opened in any text editor
Checking the Event Log
- Open Event Viewer on the Collection Server
- Navigate to Windows Logs > Application
- Filter by source "xAssets" or the discovery service name
- Look for error or warning entries that correspond to the discovery run time
Tips for Troubleshooting
- Test a single machine first. Use Discover > Discover This Computer or Another Computer with a known IP address to verify that discovery works for at least one machine before scanning an entire subnet
- Check firewall rules. WMI discovery requires TCP ports 135 and dynamic RPC ports. SNMP uses UDP port 161. SSH uses TCP port 22. Ensure these are open between the Collection Server and target machines
- Verify the PCAnalyser share. The PCAnalyser folder must be set up as a Null Session Share with NTFS permissions for ANONYMOUS LOGON and EVERYONE, so processes running under SYSTEM credentials on target machines can write data back
- Review credential packs. If discovery works for some machines but not others, the issue is almost always credential-related. Create separate Credential Packs for different network segments if needed
Related Articles
- Running Discovery — launching a discovery scan
- The PCAnalyser Folder — understanding the file share structure
- Credential Packs — creating and managing discovery credentials
- Loading Discovery Data — importing results into the database