Skip to main content

Troubleshooting auto discovery

This section describes how to identify and resolve common issues with the auto discovery process. Auto discovery stages depend on each other, so an issue in one stage can affect later stages.

Warning

Do not interrupt the psupdate process by rebooting the server, killing the process, or performing operating system or database maintenance while auto discovery is running. Depending on the stage where psupdate is interrupted, an incomplete auto discovery can introduce data inconsistencies ranging from audit discrepancies to loss of privileged credentials in Bravura Privilege.

Common symptoms

The following symptoms indicate auto discovery issues:

  • Auto discovery does not start. The psupdate process does not begin at the scheduled time or when triggered manually.

  • Auto discovery is slow or stalled. The process takes significantly longer than normal (from several minutes to hours or days), or never finishes.

  • Auto discovery completes with errors. Changes made on target systems (new users, new accounts, attribute changes) are not reflected in the web UI or reports.

Diagnostic approach

To troubleshoot auto discovery issues:

  1. Verify that the application server has adequate resources (CPU, RAM, disk space, network connectivity). Applications under resource contention cannot perform as designed.

  2. Verify that the Logging service is running and that logging is configured to record detailed execution entries.

  3. Determine the current stage of auto discovery. Navigate to Manage the system > Maintenance > Auto discovery > Execute auto discovery to view the current and recent stages. In earlier versions, filter the idmsuite.log for stage markers.

  4. Identify the specific stage where the issue occurs (listing, loading, or association) and investigate accordingly.

Auto discovery does not start

If auto discovery does not start at the scheduled time:

  1. Navigate to Manage the system > Maintenance > Scheduled jobs > PSUPDATE and verify that a node is listed. Auto discovery only runs on the primary node.

  2. If no node is listed or the page reports "Service stopped," verify that the iddiscover service is running on the primary node.

  3. Try running psupdate manually from the instance util\ directory. Check if it logs entries in idmsuite.log or displays a dialog with error information.

  4. If psupdate does not log anything, use Process Monitor (procmon) to observe what registry keys or files it attempts to read at startup.

Auto discovery is slow

If auto discovery takes significantly longer than expected, investigate the following common causes:

  • Infinite list timeouts. If a target system list timeout is set to -1 (infinite) and the connection to the target is lost, the agent binary runs indefinitely. Check for long-running agent processes on the application server or proxy.

  • Database locks. Stored procedures called by other processes or database maintenance (such as index rebuilding) can lock tables used by auto discovery. Check the Activity Monitor in Microsoft SQL Server Management Studio for blocking queries.

  • Insufficient server resources. Check for insufficient disk space on tempdb, slow disk I/O, high-latency network connections, insufficient CPU cycles or RAM allocated to the VM, or antivirus software consuming I/O.

  • Growing historical data. If slowness increases over time, the backend database may be accumulating historical data that slows stored procedure execution.

  • Complex user class criteria. User class caching can take significant time if user classes use complex criteria or API calls.

Use performance log entries in idmsuite.log (perf and perf_sproc extended levels) to identify which binaries and stored procedures are causing the slowdown.

Auto discovery errors

If auto discovery completes with errors or produces incomplete results:

  • Listing failures. Check the idmsuite.log for entries from agent binaries that explain what failed on the target or in communication with the target. Verify that the psconfig\<TARGETID>.db file contains the expected data.

  • Proxy communication failures. If a target is listed through a proxy, the proxy log may report that listing ended while psupdate never finishes listing that target. This indicates the proxy service failed to communicate listing status back to the primary node.

  • Database loading failures. Search the idmsuite.log for "Failed to call Execute" or "Source:" entries from the database client. These indicate stored procedure failures during the loading stage.

  • Duplicate entries. Search the idmsuite.log for "duplicates." If a target list file contains duplicate entries, the database update may fail and Bravura Security Fabric retains the old data from before auto discovery ran.

Verifying results

After auto discovery completes, verify the results:

  • Check the Accounts and Profiles reports to confirm that discovered data is loaded in the backend database.

  • Look for accounts marked "Deleted by other," which indicates the account was not found during the most recent listing.

  • Verify correct account-to-profile associations.

  • If listing data files exist in the psconfig\ directory but the data is not in the database, the issue is in the loading stage. If no listing files were created, the issue is in the listing stage.

In this section: