Issue
A discovery job (discovery_schedule) has a set time to start as configured in the discovery schedule record, as well as how often to run the job. This article highlights a few things to check if the discovery is not started as expected.
Troubleshooting Discovery Schedule Start
The discovery_schedule table extends the sysauto_script table which extends the sysauto table.
Like other scheduled jobs, there are a couple of items required to properly trigger a discovery:
- A sys_trigger record that details when the job will run again
- A script that runs when the job is triggered
Troubleshooting:
- Open the sys_trigger table and confirm that a sys_trigger record with the same name as the discovery schedule exists.
- If no matching sys_trigger record is found, de-activate and activate the discovery_schedule to create a sys_trigger.
- Open the discovery_schedule record and confirm the discovery_schedule.script field is properly populated, compare to a discovery schedule which starts successfully.
- If the script is missing, copy the script from the original discovery_schedule record. This issue is only seen when the discovery is imported.
- Check if there are IP Ranges which could cause issues such as and update the Ranges accordingly:
- Remove IP Ranges for /31 or /32 subnets. These are not valid ranges for discovery.
- IP Ranges for subnets which are too large (/16, /15, /13) may need to be split into smaller IP Ranges.
- Check the syslog table for any errors at the time the discovery was supposed to start.
- Compare the discovery_schedule record xml from a discovery schedule which begins successfully to one that does not.
Related Links
The following articles provide information regarding other topics in discovery schedules: