_
_
An excellent first step when troubleshooting discovery failures in ServiceNow is a simple ping test from the MID Server to the device being discovered. A ping test can indicate whether the problem may be a configuration or permissions issue when a successful ping is returned. If the ping times out, we may be looking at a powered-down device or a device that is not reachable from the MID Server because proper firewall rules are not in place. Typically, you would log into the MID Server and open a command prompt to execute a ping command. This can often slow down the troubleshooting process, especially when multiple MID Servers are being logged into. But what if we execute the ping command from our ServiceNow instance and receive a response in seconds? Let’s take a look at how we can accomplish this.
We can utilize an ecc_queue record to execute the ping command from any MID Server connected to your instance. Creating a new record with the “Agent” field populated with the MID Server of choice, the “Topic” field populated with “Command”, and finally, the “Name” field with the actual ping command will ping the device just as if you are manually doing it from the MID Server.
Creating this record is easily done in JavaScript. Notice how the same three fields from above are being addressed in this code block. Capturing the name and sysID is useful when trying to retrieve the response. We use “-n 2” at the end of the ping command. This limits the replies to only two, which in this use case provides the sweet spot regarding the time it takes to deliver the response back to the user in ServiceNow.
Filtering the ecc_queue with the “Response to” and “Name” fields is the best way to find the returned ping response. “Response to” is populated with the sysID from the created record. “Name” will be the same as the created record. Before the payload data is returned to the user, it is parsed using a regular expression.
The “Ping Test” list banner button can be found on the discovery schedules page right next to the “Quick Discovery” button. Both are good discovery troubleshooting options. This is created with a UI action. When the button is clicked, a GlideDialogWindow is rendered, which references a custom UI page.
The UI page will prompt for both the IP address and MID Server. Validation is in place to make sure the IP address entered is in proper format. Once the user provides the inputs and clicks “Okay”, a function is called in the client script on the UI page. A subflow was created to gather the inputs and wait until the response record is returned. The sub-flow also deals with parsing the payload with a regular expression, like mentioned above. To kick off the subflow in JavaScript we will need to do it from a script include since it lives server-side.
A few things to note from the script include. Notice on line 15 “startSubflow” is used instead of “executeSubflow”. Normally execute is a better option, but since we are using wait timers in the subflow, start is our only option. A little workaround is in place with a while loop that waits until flow outputs are available.
You will notice that the look and feel are very similar to a quick discovery. A “Waiting for ping response” message will pop up when you are waiting for the result. The UI page is designed to allow for multiple runs, so there is no need to exit and relaunch the page if you want to ping more than one device. Below is an example of both a failed and successful ping response.
Here are a couple more important items to keep in mind about the backend processes:
Here is the link to download the update set in RapDev’s open source repo. Ping away!
