ServiceNow Discovery: How Windows CI Discovery Works Using Probes & Sensors

maheshkhatal · 34m ago

ServiceNow Discovery: How Windows CI Discovery Works Using Probes & Sensors

🔧 Pre-Requisite

Before starting, ensure:

✅ MID Server is installed on your machine
✅ MID Server status = Validated
✅ Discovery role access

What is Discovery in ServiceNow?

ServiceNow Discovery is a process that scans your connected infrastructure to identify servers, applications, databases, network devices, and more — then automatically populates the CMDB.

In simple terms:

🔍 Discovery = Automatically understanding what exists in your IT environment.

It does this through a series of steps involving the MID Server, Probes, Sensors, and modern Patterns.

🧠 MID Server — The Heart of Discovery

The MID Server sits inside your network, acting as the secure bridge between ServiceNow (cloud) and your internal devices.

✅ Key points:

MID Server communicates to your ServiceNow instance outbound ONLY (port 443).
No inbound connection is ever opened → high security.
MID Server continuously polls the ECC Queue in ServiceNow every 40 seconds.
ECC Queue = “External Communication Channel” where all Discovery jobs sit.

MID Server looks like:

🔗 SN Instance → ECC Queue (Output)
⬇️ (MID Server polls)
⏳ MID Server performs probe
⬆️ MID Server → ECC Queue (Input)
🧠 Sensors parse data → CMDB updated

🔄 How MID Server Communication Works

Here’s the real flow of communication:

ServiceNow Instance

|

| (1) Creates a Discovery job

V

ECC Queue (Output)

|

| (2) MID Server polls & picks jobs

V

MID Server

|

| (3) Sends probe to target device

V

Target Device (Windows machine)

|

| (4) Sends raw data back

V

MID Server

|

| (5) Sends raw XML as ECC Input

V

ECC Queue (Input)

|

| (6) Sensors / Patterns parse data

V

CMDB tables updated

🤖 + 🧠 Probes and Sensors (Traditional Discovery)

Although modern Discovery uses Patterns, the traditional engine uses:

🔹 1. Probe (The Robot Scout 🤖)

A probe is like a small robotic scout that MID Server sends to a target device.

It:

connects to the device (SSH/WMI/SNMP/etc.)
gathers raw configuration data
returns unprocessed results

A probe does NOT update CMDB.

🔹 2. Sensor (The Analyst Robot 🧠🤖)

A sensor is triggered after the probe returns data.

It:

parses the raw XML
extracts useful information
writes CIs into the CMDB

📊 (Probes + Sensors)

🤖 Probe

(collects raw data)

|

| raw XML

V

🧠 Sensor

(interprets & updates CMDB)

Or visually:

Probe = "Go out and bring me whatever you see!"
Sensor = "Let me read what you brought and create CIs."

🏗️ What We Are Going to Build

We will perform a simple discovery on a Windows computer using probes + sensors.

We will even populate an extra custom field to prove discovery worked.

✅ Step 1 — Add Custom Field

On cmdb_ci_computer, create a field:

📌 Some Extra Info → String type

This field will be filled by our sensor later.

🧭 Creating the Probe

Navigate to:

👉 Navigator → Discovery Definition → Probes

Now we create a new probe

Go to Discovery Definition->Probes and Click New and create a Probe as shown below

After creating the probe, we will write a matching Sensor that processes the returned data and updates the custom field.

Go to Discovery Definition -> Sensors and Create a Sensor as shown below

The sensor code:

new DiscoverySensor({

process: function(result) {

var output=result.stdout;//stdout is the tag that contains the output of the command

current.u_extra_info=output; //assigning the result into the BIOS detail field.

},

type: "DiscoverySensor"

});

💡 As you can see, the output contains the information returned through the <result> node’s stdout tag in the XML payload(We will see it in the input xml payload when we run the discovery).

🧩 Once we’ve configured our Probe and its corresponding Sensor (which updates the Some Extra Info field 🧠), the next step is to link this Probe to the Windows Classifier — since this classifier will trigger our Probe during the Classification phase.

⚙️ Navigate to:
👉 Discovery Definition → CI Classification → Windows

🪟 Why Windows?
Because this is the Classifier that’s invoked when Shazzam detects that port 135 is open on the target device. This port is a key indicator of a Windows machine, which ensures that our custom Probe is triggered appropriately.

Finally, open the Windows record and, under the Triggered Probes related list, add the Probe you just created.

See the attached screenshot for reference

On your machine type the command as shown below:

🤖 This is the exact command we configured in our Probe — it acts like a nano-robot 🛰️ that travels across the network, collects the required information, and returns the output (as shown in the screenshot). ⚡

🧠 The Sensor then processes this returned data and updates the corresponding record in the Computer CI table within the CMDB.

Go to Discovery Schedule and Click on the Quick Discovery and type the ip address of the machine that is to be discovered and select the mid server. Click Ok , discovery will begin now

Quick summary of the 5 phases of the discovery

Scanning

MID Server identifies reachable IPs using Ping, SNMP, WMI, SSH, etc.

Classification

Determines what type of device it is (Windows, Linux, Network device, Database, etc.).

Identification

Finds unique identifiers (serial number, BIOS UUID, MAC, etc.) to map to an existing or new CI.

Exploration

Gathers deep technical details about the device (CPU, RAM, software, services, ports, etc.).

CMDB Identification & Update

Compares discovery results with CMDB and creates or updates CI records.

⚡ Shazzam, being the first phase of Discovery, checks whether the target machine is active and reachable 🖥️.

Once it confirms connectivity, Shazzam analyzes the open ports to determine the type of device — for example, if port 135 is open, it classifies the device as Windows, whereas port 22 indicates a Linux system 🪟🐧.

📡 To understand this better, open the ECC Queue records for both the Output (sent to the MID Server) and Input (returned to the ServiceNow instance). Reviewing these XML payloads will give you a clear picture of how Discovery communication flows between ServiceNow and your target system. 🔍

📂 If you open the input payload for Shazzam, you’ll notice that port 135 is open — this indicates that the target device is a Windows machine 🪟.

Because of this, the Windows Classifier will be selected in the next classification phase.
💡 Had port 22 been open instead, the Linux Classifier 🐧 would have been triggered — and similarly for other operating systems based on their respective ports.

See the Shazzam input xml payload:

Now in the ecc Queue tab open the Topic where Command is mentioned and go through the XML Payloads for both output and input records.

The Output XML Payload: Observer the sys ids of the Probes, classifier etc.

<parameter name="os_type" value="WINDOWS"/>

<parameter name="probe_name" value="Windows Mahesh Probe"/>

<parameter name="probe" value="d5802d0483fc32107412f4b6feaad381"/>

<parameter name="classification_probe" value="b11360600a0a0ba500c41bcbae55c5c4"/>

</parameters>

The Input XML Payload which has returned the data:

<result command="systeminfo | find "Original Install Date"">

<stdout>Original Install Date: 05-09-2025, 22:30:39</stdout>

</result>

</parameters>

</results>

🧠 Recall that in our Sensor, the <result> node’s stdout tag contains the output of the command:

systeminfo | find "Original Install Date"

We then store this value in the custom field current.u_extra_info. 💾

Once the Discovery process completes all its phases, this value is automatically updated in the cmdb_ci_computer table for the discovered Configuration Item (CI). 🖥️

Open the newly discovered CI record, and you’ll see the ‘Some Extra Info’ field populated with the command’s output.

📸 Refer to the screenshot below for a visual confirmation.

🎉 This marks the successful completion of our Discovery process using Probes and Sensors — the traditional yet powerful method to collect and populate configuration data in the CMDB. ⚙️

In the next article, we’ll take this a step further by exploring how to use Discovery Patterns 🧩 to gather additional and deeper insights about the same Windows CI. Stay tuned! 🚀