After a Clone, a Discovery Schedule for a Specific MID Server, which does not exist in the target instance and so is now a broken reference, will still run in a random MID Server.
The MID Server field of the Discovery Schedule record will contain a value, although it is a broken reference due to all MID Servers having unique sys_ids and being specific to instances.
This causes cause performance problems on sub-prod instances where Discovery will be run in MID Servers that are not set up or intended for Discovery, or cause performance issues on the network/target devices due to unwanted discoveries running.
Steps to Reproduce
- Install Discovery and a MID Server, in the instance that is to be the source of the clone (usually Production)
- Create a scheduled daily Discovery Schedule, set to run with the above Specific MID Server
- Clone that instance to another instance (usually Dev).
- That schedule will have been copied during the clone. It will run, and pick a random MID Server, even though the schedule is set to only run in the specified MID Server.
The expected behaviour is that the Discovery starts and immediately completes without launching Shazzam, because the specified MID Server does not exist.
This problem has been fixed. If you are able to upgrade, review the Fixed In or Intended Fix Version fields to determine whether any versions have a planned or permanent fix.
The workaround to guarantee the issue does not happen after a clone is to shut down all clone target MID Servers before the clone. Discovery Schedules can be made inactive immediately after the clone, or configured to use equivalent clone target instance MID Servers.
Related Problem: PRB1311068