"Discover Now" Bug - Trigger Full Schedule Discovery!

[Jaskaran Walia]

We are in middle of upgrade to Quebec as part of early access program. We noticed an issue with "Discover Now" UI action on a configuration item that I wanted to share with the community.

Issue:

"Discover Now" UI action on a Configuration item is causing the full discovery schedule to when when the schedule is using behavior of multiple phases. The intended behavior should be to run discovery for that CI only.

Example of Discover Now UI action on a CI:

Example of Discovery schedule that use behavior

Resolution:

We logged HI case and they have confirmed the bug in quebec with intended fix in future release.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0954590

Workaround:

The workaround is to use "Quick Discovery" button on the Discovery Schedules table to start a discovery to a single device.

Hope this saves you guys time investigating the bug and workaround.

Happy Knowledge sharing! If you find this helpful, Please do mark it helpful.

Thanks,

Jaskaran Walia

[doug_schulze]

Wow, that is one very specific use case! And surprisingly I have never come across that so thanks for the tip. 

This does bring up an important thought on using behaviors though. Behaviors as you know are how we are able to generate up a protocol (WMI/SSH/SNMP ect) based discovery to help limit the port probe checks we do in the shazzam phase. Back in the "Horse-drawn Discovery Days" as I like to say, behaviors also gave us the first concepts of mid-server load balancing and assignment of classification probes to mids that were running as a user in the same domain as identified by the WINS return. Well with the advent of Clusters and Powershell discovery, the first two capabilities have grown quite dusty. But its base structure is the source of this challenge.

Originally, our thought was to use phases as a 'sieve' if you may. That if in Phase 1 I have WMI as my functionality I scan all the IP addresses for port 135, those that are discovered moved on with the Discovery process. For those that did not? Well, those IPs were 'supposed' to fall through to phase 2 (if configured) to see if any SSH ports, for example, were open .. so on, and so forth..

It just unfortunately never worked out, our dear friend JED of course says hello. For all this time when using phases, we scan any identified IP range in phase 1 and then still scan the entire IP range once again in subsequent phases. And why this is happening. The UI action looks to see the last schedule that discovered that system. And why it "looks" like a full schedule discovery is taking place but in fact, we are only using the instructions of the Schedule; mids, clusters, (ahem) behaviors to kick off the single IP scan. However, with the phases defined, the process takes over and says 'I got a phase two for 'this' schedule' lets get that rolling.

In this use case, you hit the jackpot in a combo, as it seems many others have since there's a KB about it.