Hi @MDAQUIBK ,
Lets discuss Why this is happening
After the Yokohama upgrade, this usually happens because:
* Discovery schedules were created without proper MID Server selection or missing credentials.
* New platform checks introduced in Yokohama (e.g., platform hardening and validation) automatically cancel discovery if critical prerequisites aren't met.
* Sometimes, customization, corruption in discovery schedule records, or MID Server / capabilities mismatch triggers the cancel signal.
The cance_discovery command in ECC Queue is intentionally sent by the platform when it detects:
* No valid MID Server.
* Missing credentials.
* Schedule configuration invalid or inconsistent.
Solution: Step by Step
Step 1: Check Discovery Schedule Configuration
* Go to Discovery → Discovery Schedules.
* For each schedule that got canceled:
* Confirm it has:
* 1.At least one valid MID Server or MID Server capability assigned.
* 2.Proper IP ranges / CI scope.
* 3.Valid and active credentials (Windows, SSH, SNMP, etc.).
* If MID selection is “auto,” confirm there are MID Servers matching the required capabilities and are Up.
Step 2: Verify MID Server Health
* Go to MID Server → Servers:
* Confirm status is Up.
* Check logs for any heartbeat issues or communication problems.
* Make sure the MID Servers are upgraded to the Yokohama version agent (matching the platform version).
* Confirm no duplicate MID Server names or conflicts.
Step 3: Validate Credentials
* Go to Discovery → Credentials.
* Ensure:
* Active = true.
* Test credentials using “Validate” button.
* Remove or deactivate stale or test credentials that might conflict.
Step 4: Check Capabilities & MID selection rules
* If schedules use MID Server capabilities (e.g., “Windows,” “SSH”), confirm MID Servers have those capabilities assigned.
* Check MID Selection Rules (Discovery → MID Selection Rules) if present:
* Rules should correctly match schedules.
* Avoid conflicting rules that might resolve to no MID.
Step 5: Look at the ECC Queue
* Go to ECC Queue → All.
* Filter:
* Topic: SystemCommand
* Name starts with cance_discovery
* Check:
* Source: which MID or process is sending the cancel.
* Payload / parameters: sometimes includes why.
Step 6: Check for Skipped / Cancel Conditions
* In Discovery Schedule → Advanced tab:
* Review “When to skip / cancel”.
* Ensure no conditions match your ranges unexpectedly.
Step 7: Review Known Issues
* ServiceNow Yokohama release notes / known issues:
* There were known issues where Discovery schedules could auto-cancel due to invalid ranges or missing credentials:
* https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1466658 (example).
* Apply any patches / hotfixes if relevant.
Step 8: Recreate / Clone Schedules
* Sometimes Discovery schedules can get corrupted during upgrades.
* Clone the schedule or recreate a fresh schedule, test again.
Step 9: Upgrade MID Servers
* Confirm MID Server is updated to match Yokohama release.
* Restart MID Server service.
Extra: Platform Debug
* Enable discovery log at debug level to get detailed logs:
* System Logs → Debug → Enable for discovery.log or MID communication logs.
* Watch the logs to see exactly when / why the cancel command is sent.
Summary Table:
MID Server - Status = Up, upgraded to Yokohama
Credentials - Active, tested, assigned to schedules
MID selection - MID selection rules and capabilities correct
ECC Queue- Look for cance_discovery details
Discovery Schedule - Properly configured, valid IP ranges
Patches - Apply any Yokohama known fixes
If issue persists:
* Open a ServiceNow HI support case.
* Share ECC logs, sys_id of the discovery schedule, and MID logs.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
ServiceNow Community MVP 2025
