ServiceNow ITOM Discovery is an automated process that scans the network to find IT infrastructure components — servers, applications, network devices, databases — and automatically creates or updates CI records in the CMDB without manual data entry.

Before Discovery, CMDB data was entered manually — a process that is slow, error-prone, and never current. By the time a spreadsheet was populated, half the data was already stale. Discovery eliminates this by scanning infrastructure on a schedule and keeping the CMDB continuously updated.

Operating systems (Windows, Linux, AIX), hardware details, IP addresses, installed software, running processes, network gear (routers, switches, firewalls), storage arrays, databases, and — with Service Mapping — the relationships between them.

Discovery sends a ping (ICMP) to every IP address in the configured Discovery Schedule range. IPs that respond are identified as active and passed to the next phase. IPs that do not respond are skipped.

Discovery determines what type of device is at each active IP — is it a Windows server, a Linux host, a Cisco router, a printer? It does this by checking which ports are open and attempting initial banner grabs. The result is a device class (e.g., cmdb_ci_win_server).

Discovery compares the discovered device against existing CMDB records using Identification Rules (part of IRE). If a matching CI is found, Discovery updates it. If no match is found, a new CI is created.

Discovery dives deep into the device — collecting hardware specs, installed software, running processes, network interfaces, storage, and dependent services — using Probes, Sensors, and Patterns specific to that device class.

A MID Server (Management, Instrumentation, and Discovery Server) is a Java application that runs on a Windows or Linux server inside the customer’s network. It acts as a bridge between the ServiceNow instance (which lives in the cloud) and the internal network that needs to be discovered.

The ServiceNow instance cannot reach internal IP addresses directly — your data center servers are behind firewalls, VPNs, and private subnets that are inaccessible from the internet. The MID Server lives inside that network, so it can reach those devices. Discovery instructions travel from ServiceNow → MID Server → target device, and results travel back the same path.

The MID Server initiates an outbound HTTPS connection to ServiceNow. No inbound ports need to be opened on the firewall for ServiceNow to reach the MID Server — this is a common interview point. All communication is initiated by the MID Server.

A Probe is an instruction set that the MID Server executes against a target device to collect raw data. A Probe tells the MID Server: "go to this IP, use WMI/SSH/SNMP, and run these commands". The MID Server executes the Probe and returns raw output.

A Sensor is a JavaScript script that runs on the ServiceNow instance to parse the raw output returned by the Probe. The Sensor reads the raw command output and translates it into structured CI attribute values that get written to the CMDB.

A Pattern is a newer, more powerful alternative that combines Probe and Sensor logic into a single declarative definition. Patterns run on the MID Server itself (not split between MID Server and instance) and can discover complex multi-layer application stacks. Patterns are the recommended approach for application discovery on modern ServiceNow versions.

Scans a range of IP addresses to find and catalog all devices on the network — servers, routers, switches, virtual machines, storage devices. This is what most people mean when they say “Discovery.”

Starts from a known entry point (a URL or IP) and maps all the infrastructure components that support that service — web servers, app servers, databases, load balancers. Builds Application Service maps in the CMDB.

Discovers resources in public cloud environments (AWS, Azure, GCP) using cloud APIs rather than network scanning. Finds VMs, storage buckets, databases, load balancers, and cloud-native services.

A lightweight agent installed on each target machine that reports its own configuration data to ServiceNow. Used when network-based scanning is blocked or for deep OS-level data collection.

The ECC Queue (External Communication Channel Queue) is the message bus that connects ServiceNow and the MID Server. Every instruction sent to the MID Server (Probe execution, scan job) and every result coming back from the MID Server (raw discovery data) passes through the ECC Queue.

agent — the MID Server this message is for.
topic — the type of message (e.g., “Command”, “Output”).
queue — direction: “input” (ServiceNow to MID), “output” (MID to ServiceNow).
state — lifecycle: Ready → Processing → Processed / Error.
payload — the actual data (probe instructions or collected output).

If Discovery is hanging or not creating CIs, the ECC Queue is the first place to check. Rows stuck in “Ready” state mean the MID Server is not picking up work. Rows stuck in “Processing” mean the MID Server is working but not completing. “Error” state rows contain the failure reason.

Discovery requires credentials to log in to target devices and collect detailed configuration data. Without credentials, Discovery can only identify that a device exists (from ping response) but cannot read hardware details, installed software, or running processes.

Windows credentials (domain or local admin account) are needed for WMI queries. The account needs sufficient permissions to query WMI namespaces — typically local administrator or a purpose-built read-only discovery account.

SSH credentials (username/password or SSH key pair) are used to run remote commands. The account typically needs read access and, in some cases, limited sudo rights for specific commands.

SNMP community strings (v1/v2c) or SNMP v3 credentials (username, auth protocol, priv protocol) are used for routers, switches, and firewalls.

In ServiceNow under Discovery Credentials records. The MID Server retrieves them at runtime and uses them against target devices. Credentials are never stored on the MID Server itself.

A Discovery Schedule defines what to discover, when to discover it, and which MID Server to use. It is the primary configuration record for triggering Discovery runs.

IP Ranges — The CIDR blocks or IP ranges to scan (e.g., 10.0.0.0/8).
MID Server — Which MID Server (or MID Server cluster) handles the scan.
Timing — How often to run: hourly, daily, weekly, or a custom cron expression.
Behaviors — Rules that modify how specific device types are handled during this schedule.
IP Exclusions — Specific IPs or ranges to skip even if they fall inside the IP Range.

Every time a Discovery Schedule runs, a Discovery Status record is created. This record tracks how many IPs were scanned, how many CIs were created or updated, how many errors occurred, and the overall run duration.

A Discovery Behavior is a named configuration that controls how Discovery handles a specific category of device during a schedule run. Think of it as a policy override for certain device types.

Which Probes to run for a given device type.
Whether to discover specific application stacks (e.g., Oracle, SAP, Apache).
Whether to follow network relationships during exploration.
Timeout and retry settings for slow-responding devices.

Restricting Discovery of sensitive servers to read-only OS-level data only (no application discovery).
Enabling deep SAP or Oracle application discovery for specific IP ranges without enabling it globally.
Reducing scan depth for network segments where Discovery is permitted but must be lightweight.

CI Identification is the process of determining whether a discovered device already exists in the CMDB or needs to be created as a new CI. Getting this right prevents duplicate records.

IRE (Identification and Reconciliation Engine) is the framework that runs Identification on every CI write. When Discovery collects data about a server, it does not write directly to cmdb_ci. Instead, it submits the data to IRE, which applies configured Identification Rules to find a matching CI.

Primary Identifier — The most reliable, unique attribute (e.g., serial number). If this matches, IRE considers it a definitive match.
Secondary Identifier — Used when the primary is not available (e.g., UUID + MAC address).
Tertiary Identifier — A fallback, usually name + IP. Less reliable, can cause false matches.

Port 443 (HTTPS) — outbound from the MID Server to the ServiceNow instance. This is the only port that needs to be opened toward the internet.

Port 445 / 135 — WMI (Windows targets).
Port 22 — SSH (Linux / Unix targets).
Port 161 — SNMP (network devices, printers).
Port 80 / 443 — HTTP/HTTPS (web servers, application discovery).
Port 1433 / 1521 / 3306 — SQL Server / Oracle / MySQL (database discovery).

The MID Server must be placed in a network segment with firewall access to all target IP ranges. If the MID Server cannot reach a device on the required port, Discovery silently skips that device or returns a “Connection refused” error in the ECC Queue. No firewall rules need to be opened inbound to the MID Server itself.

Scans entire IP ranges looking for all devices. The goal is broad inventory coverage — find every server, device, and application in a subnet and create CI records for each. Discovery does not care about relationships between CIs — it just creates them.

Starts from a known service entry point (e.g., a URL for the Banking Portal) and maps all dependencies — load balancers, web servers, app servers, databases — building a complete Application Service map. Service Mapping is relationship-focused: it creates the dependency links that make impact analysis and CSDM meaningful.

Discovery first — build the CI inventory. Service Mapping after — build the service map on top of that inventory. Both run in parallel in mature implementations: Discovery keeps CIs current, Service Mapping keeps relationships current.

When Discovery finds a device that matches an existing CI (via IRE Identification Rules), it does not create a new record. Instead, it runs the discovered attributes through IRE’s Reconciliation process before writing any updates.

Reconciliation Rules define which data source is authoritative for each attribute. If Discovery is the authoritative source for ip_address and os_version, those fields are updated. If a field is owned by “Manual Entry” or another source, Discovery’s values are blocked from overwriting it.

ServiceNow tracks which source wrote each attribute via the sys_object_source table. This allows Reconciliation to enforce authority and allows admins to audit which source last modified a field.

Every Discovery Schedule run creates a Discovery Status record on the discovery_status table. It is the audit log and health check for a Discovery run.

state — Running, Complete, Cancelled, Error.
start_time / end_time — Duration of the run.
ips_discovered — How many IPs responded to scanning.
cis_created — New CI records created in this run.
cis_updated — Existing CIs updated with fresh data.
errors — Count of errors encountered.
mid_server — Which MID Server processed this run.

Each Status record links to individual Device History records, showing exactly what happened for each IP address — which Probes ran, which CI was created or updated, and any errors that occurred at the device level.