22 views

Overview


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 items required to properly trigger a discovery:

  1. A sys_trigger record which details when the job will run again
  2. A script that runs when the job is triggered

Troubleshooting:

  1. 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.
  2. 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.
  3. 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.
  4. Check the syslog table for any errors at the time the discovery was supposed to start.
  5. Compare the discovery_schedule record xml from a discovery schedule which begins successfully to one that does not.

 Additional Information


The following articles provide information regarding other topics in discovery schedules:

Article Information

Last Updated:2018-08-28 11:06:54
Published:2018-08-28