My ToolBox

[doug_schulze]

Being the guy who goes out in the field deploying the Discovery product, like any good workman I come with a bag full of "tools" to help identify and troubleshoot discovery problems when scanning networks...

Now SlightlyLoonys blog is schooling us all in the common sense workings of the pieces of discovery sometimes you have to step outside the product to validate the results you are getting. So I'm going to kick off my blog by going through the tools I use when deploying and helping my friends get their assets into their CMDB with absolute confidence and trust in the results. So with that said.....

Many times Service Now Admins cannot discover a particular device because of errors identified in the ECC queue. Being that organizations can be pretty vast there are times that you may have to go to other responsible groups for these devices to tell them something is broke... and as it is in our Judicial system its up to us (the accusers) to prove its not our product or application....

So being able to have that information readily available as you troubleshoot and escalate can make all the difference....So lets start with

1. Be sure that you are logging into you mid-server (datacollector) host under the same credentials that you have started your mid server application with. This will help you ensure you are approaching the target with the same permissions as the application is and applies to Windows and Unix systems alike.

2. Ping. First and foremost we must be able to ping the device and get a response from the device.

Start > Run > CMD will kick out a command line window where you can type:

c:/>ping 10.10.10.2 (IP of the target you wish to reach)

3. The Magic of Telnet. Telnet should become your best friend, I'm sure those graybeards (no offense sir) out there can remember the days when port 21 was the Route 66 in computer communications with all these newfangled wingdings such as SSH, RDP, SNMP, WMI the old road may have been forgotten. Being that things have evolved so, telnet still has its uses and it can tell you allot. Whenever I cannot connect to an instance on port 443 (https) or particular target machine we get right on the MidServer (data collector) host and see if we can connect to the target on a straight TCP connection.

Start > Run > CMD will kick out a command line window where you can type something such as:

c:/>telnet instance_name.service-now.com 443

Or

c:/>telnet target.hostname 22

*note telnet by default will try and connect on port 21. By specifying the port at the end of your string you can define what 'road' it takes...

This will tell you if we can or cannot connect on one of the lowest levels of IP communication that you most likely "control" from the host outside our application. After hitting enter and you get a blank screen you've made the base connection and time to move up the OSI model. But when it fails you'll see an error.

Remember with telnet you can connect to most any port, akin to knocking on a door in your neighborhood and see if someone will answer, Ping will tell you if the door is there, telnet will tell you if it will open. So with telnet even though we won't be able to prove our credentials we can at least see if we can get the chance to present them in the first place....

Do know some ports do not work on the TCP model.. SNMP for instance is a UDP, connectionless protocol and telnet cannot help us there, but we'll talk more about that later...