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.
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.
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!
A ServiceNow Engineer with a passion for automation. He began his career in infrastructure and thrives when merging it with ServiceNow. He consistently solves business challenges using code. Off work, he’s likely spending time with his family or playing golf.