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 · Accepted solution]

@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.

[AshishV39002515]

Hi @SamRodriguez ,

I would suggest below approaches to make sure discovery will run smoothly in service now instance irrespective to any version -

Before excluding individual IP addresses, I would recommend addressing the root causes:

1. Clean up/Deactivate/Remove empty and unused subnets.
2. Resolve credential failures and implement credential affinity.
3. Use centralized IP exclusions instead of schedule-specific exclusions.
4. Tune discovery timeouts and port scanning behavior.
5. Segment discovery schedules logically and distribute the load across MID Servers.
6. Review MID Server performance and Discovery Status logs to identify bottlenecks.

In most environments, credential issues and inactive IP ranges are the biggest contributors to long-running discovery schedules, and addressing these areas typically provides significant performance improvements.

Please mark this as Correct Answer/Helpful if it helped you.

Thanks & Regards,

Ashish Verma

[SamRodriguez]

Thanks, this is really helpful and aligns with what I’m seeing.

I’ll continue to focus on:

• Cleaning up credential failures and tightening affinity
• Removing invalid/empty subnets (leveraging Infoblox)
  • Currently in the planning stages
• Reducing Shazzam time on non-responsive IPs
• Validating MID capacity/load balancing and ECC backlog
• Tuning timeouts to avoid delays on dead hosts

This is also a helpful approach, I’ll also use behaviors and better schedule segmentation (by tech/region) and prioritize fixes based on top Discovery log failures.

Longer term, I’m aligned on shifting away from broad IP scans toward IPAM/integration-driven discovery.

Appreciate the guidance

[shubhamseth]

Hi @SamRodriguez Thank you! I am glad that it clarifies your queries! Please accept it as solution so it can be benefits for others in future.