Discovery Architecture — How ServiceNow Finds What's on Your Network

What Is ServiceNow Discovery?

In Part 2 you learned that Service Graph Connectors pull data from external APIs — they ask a cloud provider or monitoring tool "what do you know about your assets?" Discovery is different: it goes out and asks the assets themselves. It scans IP addresses directly, connects to each device or server, and reads its configuration.

Think of the difference this way:

• SGC: Asks the hotel's front desk for a guest list
• Discovery: Knocks on every door and asks who's there directly

Discovery can find things that APIs don't expose: the exact version of software running on a server, the precise CPU model, all installed services, running processes, open ports, configuration file contents. This depth of data is why Discovery remains essential even when SGCs are in use.

ServiceNow Discovery has been part of the platform since the Eureka release (2013) and has gone through major evolution. The modern Discovery platform (Washington DC and later) uses a pattern-based approach that is more robust than the older probe/sensor approach. Both exist today; the exam covers both.

Horizontal vs. Vertical Discovery — The Two Phases

Every Discovery run executes in two phases, which ServiceNow calls Horizontal Discovery and Vertical Discovery. Understanding the difference is critical — it's one of the most commonly tested Discovery concepts.

Horizontal Discovery — Finding What Exists

Horizontal Discovery sweeps across a range of IP addresses to answer one question: "What is at this IP address, and is it alive?"

It's called "horizontal" because it scans broadly across many IPs — a wide sweep across your network. Horizontal Discovery uses two mechanisms:

• Port scanning: Sends TCP connection attempts to common ports (22 for SSH, 135/445 for Windows, 161 for SNMP, 443 for HTTPS). An open port means something is listening.
• ICMP ping: Sends a ping to check if the IP is reachable. Note: many firewalls block ICMP, so Discovery doesn't rely on ping alone.

The output of Horizontal Discovery is a list of discovered devices with their IPs and open ports. At this stage, Discovery doesn't know much about them — just that they exist and are reachable.

Vertical Discovery — Classifying and Detailing What Was Found

Vertical Discovery goes deep into each device found by Horizontal. It answers: "What exactly is this device? What is it running? What are all its properties?"

It's called "vertical" because it digs down into each individual device. Vertical Discovery uses the open ports found by Horizontal to choose the right protocol to connect with:

• Port 22 open → try SSH → if successful, run shell commands to get OS, CPU, memory, disk, installed software
• Port 135/445 open → try WMI (Windows Management Instrumentation) → get Windows-specific inventory
• Port 161 open → try SNMP → get network device details (MIBs for switches, routers)
• Port 443/80 open → try HTTPS/HTTP → identify web servers, application servers

The output of Vertical Discovery is a rich CI record with populated fields: OS name and version, CPU count and model, memory, storage, running services, installed software, network interfaces, and more.

Discovery Schedules — Controlling When and Where Discovery Runs

Discovery doesn't run randomly — it's controlled by Discovery Schedules. A schedule defines:

• What to scan: IP ranges, specific IP addresses, or networks
• When to scan: Cron-based schedule (daily at 2 AM, every 4 hours, weekly)
• Which MID Server to use: Based on IP range assignment
• Behaviors: Whether to run full scan or targeted behaviors

Schedule Types

• IP Range Schedule: Scans all IPs in a specified CIDR range (e.g., 10.0.0.0/24). Most common type. Can specify multiple ranges.
• Single Device Schedule: Scans a specific IP or hostname. Used for targeted rescans after configuration changes.
• CMDB CI Schedule: Re-scans CIs that already exist in the CMDB. Useful for verifying that known CIs haven't changed.

Discovery Schedule Configuration Fields

The Complete Discovery Run Lifecycle

When a Discovery Schedule fires, it goes through a precise sequence of phases. Understanding this lifecycle helps you diagnose what went wrong when Discovery produces incomplete results.

Discovery Status — Monitoring a Run

Every Discovery run creates a Discovery Status record visible at Discovery → Discovery Status. This record shows:

• Number of IPs scanned
• Number of CIs created / updated / skipped
• Number of errors per phase
• Which MID Servers participated
• Timeline: when each phase started and completed

The Discovery Status is your primary diagnostic tool. When Discovery doesn't create a CI you expected, check the Discovery Status record for that IP.

Discovery Behaviors — Controlling What Gets Scanned

A Discovery Behavior is a named configuration that controls which probes and patterns run during Discovery. Think of it as a "scan profile" that you attach to a schedule.

Default behaviors shipped by ServiceNow include:

• All Active Servers: Discovers servers via SSH and WMI; collects full OS inventory
• Network Devices: Focuses on SNMP-based discovery of switches and routers
• Cloud Compute: Optimized for cloud instances; uses cloud APIs plus agent
• Agentless: Credential-based scan without installing anything on the target

What a Behavior Controls

Discovery Inclusions, Exclusions, and CI Identification

Including and Excluding Specific IPs or Ranges

Within a Discovery Schedule, you can add:

• Include ranges: Specific CIDR blocks or IP ranges to scan (e.g., 10.0.1.0/24 and 10.0.2.0/24)
• Exclude ranges: Specific IPs or ranges to always skip, even if they fall within an included range (e.g., 10.0.1.50 is a fragile legacy system — never scan it)
• IP classification rules: Mark certain IP ranges as "printers only" or "network devices only" to limit which probes run

How Discovery Identifies CI Types

During Vertical Discovery, after connecting to a device, Discovery must decide: "Is this a Windows server? A Linux server? A Cisco router?" This classification is done through CI Type Identification, which checks:

1. What ports are open?
2. What protocol responded (SSH replied with Linux banner vs. WMI replied with Windows data)?
3. What did the initial fingerprint probe return?

Based on this, Discovery selects the appropriate probes (or patterns) to run in depth.

The Classification Hierarchy

CI type classification follows the CMDB class hierarchy (fully covered in Part 5):

• Linux server with Apache → cmdb_ci_linux_server + cmdb_ci_appl_apache
• Windows server → cmdb_ci_win_server
• Cisco switch → cmdb_ci_network_adapter → parent class chain to switch-specific table

Discovery vs. Service Graph Connectors — When to Use Which

Discovery Troubleshooting — Common Failure Patterns

Scenario 1: IP Is in Scope but No CI Created

Discovery Status shows the IP was scanned but no CI was created.

• Check if horizontal succeeded: is the device pingable / are ports open?
• If ports are open: check if credentials are configured for that IP range
• If credentials exist: check if an Identification Rule exists for the expected CI class
• Check MID Server logs for connection errors

Scenario 2: CI Created but Missing Fields

A CI exists for the server but CPU, memory, and software are blank.

• Horizontal succeeded but vertical probe may have partially failed
• Most likely: wrong credentials (SSH key format issue, expired password)
• Or: firewall allowed port 22 connection but blocked specific commands
• Check the probe log in the Discovery Status for the specific error message

Scenario 3: Duplicate CIs Created

Discovery creates a second CI for the same physical device.

• IRE Identification Rules may be missing or misconfigured for that CI class
• The device may have multiple IPs, and Discovery found it on two different IPs without correlating them
• A device was renamed — old CI still exists; Discovery created a new one with the new name
• Resolution: use IRE Deduplication features (Part 4)

Scenario 4: Discovery Runs Slowly

• Too many IPs in one schedule chunk — split into multiple smaller schedules
• Too few MID Servers — add more to distribute load
• Network is slow — Discovery is I/O bound when connecting to many devices
• Vertical Discovery timing out — some devices respond slowly to probes; increase timeout values

Practice Questions

4 questions · Select an answer to see the explanation immediately.