Long running discovery schedules

[SamRodriguez]

First time poster.  I've been working on discovery optimization, breaking down large schedules into smaller more digestible schedules.  I've had much success with the schedules I built out, but, they're running longer than expected..in some cases there are credential issues and empty subnets.  so, I've been finding myself excluding IP Addresses in many of the subnets in the schedules trying to get them to run faster.  Any suggestions anyone can provide how I can address this issue would be greatly appreciated. 

[shubhamseth]

@SamRodriguez You are already spot on: 

Areas to Review

• Credential Issues: Failed credential attempts can significantly increase Discovery duration. Review Credential Affinity and Discovery Status logs to identify repeated authentication failures.
• Empty Subnets: Consider removing unused subnets from schedules instead of excluding individual IPs.
• Shazzam Performance: Verify that Discovery is spending time on actual devices and not repeatedly scanning non-responsive IPs.
• MID Server Capacity: Check MID Server CPU, memory, thread count, and ECC queue backlog.
• Timeout Settings: Excessive SSH/WMI/SNMP timeouts can slow schedules considerably.

Recommendations

1. Use Behaviors to limit unnecessary probes and classifications.
2. Create schedules based on technology, region, or network zone.
3. Review Discovery Logs for the top failure reasons and address those first.
4. Use IP Ranges/Subnets that are known to contain managed devices.
5. Consider Cloud Discovery or integrations where applicable instead of large IP-based scans.