How do I determine why Discovery is not discovering a server?

[rmeyer]

The IP for the server is within a scheduled range. I have also tried Discover CI for the specific IP. I have the ECC Queue input results from Shazzam. The input results contain the DNS but no CI is created or updated (CI actually already exists but has a different IP which I thought that Discovery should be updating for me).

[Stijn Verhulst3]

Hi Roger,

- Does the Discovery Log of the Status record mention something specific (warnings, errors)?

- What do the "Identity" lines say in the Discovery Log of the Status record?

Kind regards,

Stijn

[rmeyer]

Stijn - Sorry it took a while to respond. I needed to get access to the logs. The only warnings I see in the log in the time frame of the run are:

        WARNING *** WARNING *** Resource does not exist: /scs/snc_node_disable.html

        worker.4 WARNING *** WARNING *** Get for non-existent record: task:37ee545bf4a09a0078d05da70fa951de, initializing

        WARNING *** WARNING *** java.net.SocketTimeoutException: connect timed out when posting to https://nodestats.service-now.com/ecc_queue.do?SOAP

Don't know if these belong to my run or to something else that my have been going on in the system at the same time.

I do not see any "Identity" lines in the log.

Please note that some CIs are getting updated but not others. The ECC queue no longer shows anything (guess it aged off overnight) but while it was out there it did indicate that Shazzam was able to determine the name of the device at the IP address so it did get part way through the process for the devices in question.

[tim_broberg · Accepted solution]

Roger, if you look at the shazzam input record on the ecc queue, you should see the results for his port scans.

SunOS solaris_pfexec 5.10 Generic_147441-01 i86pc<community_string>public<snmp_version>0<banner_text>SSH-2.0-Sun_SSH_1.1.4<banner_bytes>.53.53.48.2d.32.2e.30.2d.53.75.6e.5f.53.53.48.5f.31.2e.31.2e.34.0a.

For the device to discover, it needs, result="open", for the relevant ports. For example, unix servers will not discover if port 22 is open (or a separate port probe is created for other ssh ports).

[rmeyer]

Tim - Thanks for the info.   Two of the ports do not have a result of open:

<scanner service="ms-nb-ns" result="unresolved" protocol="udp" portprobe="wins" port="137" name="NBT"/>

-<scanner service="dns" result="resolved" protocol="udp" portprobe="dns" port="53" name="DNS">

I thought I had seen somewhere that 137 and 53 both did DNS lookup so I figured since the port 53 lookup returned the DNS that all was ok. If nothing else I had assumed it would do what work it could and at least indicate it had found the server and list it in the devices tab. Guess not.

So it sounds like I need to have port 137 opened (or at least find out why it is not open). Is 53 ok with a result of resolved or do I need to do something there also?

Supposing this resolves my issue is there any way, short of looking in the Shazzam input record for every scheduled Discovery, to know which items have been missed? I only knew to did into these 2 servers because I already knew we had bogus info for them in the CMDB and went looking to find out why. I am concerned I could have other servers with similar issues (non-open ports) and no way of knowing it. Guess maybe I could have the infrastructure team check all servers to see if the appropriate ports are open?

-Roger