Patterns, Probes & Credentials — How Discovery Reads Your Infrastructure

The Data Collection Challenge

Horizontal Discovery found 250 live devices in your IP range. Now Discovery must connect to each one and extract specific configuration data — OS version, CPU model, installed software, running services. But there's a fundamental challenge: each device type responds differently.

• A Linux server accepts SSH connections and responds to shell commands like uname -a
• A Windows server accepts WMI queries — its own Microsoft-specific inventory protocol
• A Cisco router responds to SNMP requests using MIBs (Management Information Bases)
• A VMware ESXi host has its own proprietary API
• An Oracle database needs a JDBC connection with its own query syntax

ServiceNow needs a framework to handle all these device types and protocols without writing completely custom code for each one. That's exactly what Probes, Sensors, and Patterns provide.

Probes and Sensors — The Legacy Model

The original Discovery framework uses two components that work as a pair: the Probe collects raw data; the Sensor processes that raw data into structured CI fields.

What a Probe Does

A Probe is a set of instructions (JavaScript) that runs on the MID Server to:

1. Connect to a target device using a specific protocol (SSH, WMI, SNMP, etc.)
2. Execute specific commands or queries
3. Return the raw output to ServiceNow via the ECC Queue

Examples of built-in probes:

• Unix Probe: SSH connects to Linux/Unix; runs uname -a, cat /etc/os-release, df -h
• Windows Probe: WMI connects to Windows; queries Win32_OperatingSystem, Win32_Processor, Win32_LogicalDisk
• SNMP Probe: SNMP v1/v2c/v3 queries for network device MIBs
• TCP Probe: Port scan during horizontal discovery
• Registry Probe: Reads Windows registry for installed software

What a Sensor Does

A Sensor is JavaScript that runs on the ServiceNow instance (not MID Server) to:

1. Receive the raw output from a Probe
2. Parse it (split strings, extract values from JSON/XML/text)
3. Build structured CI payloads (setting specific field values)
4. Pass the payload to IRE for CMDB update

The Probe/Sensor relationship is always 1:1 — each Probe has a corresponding Sensor. The Probe says "here's what the device said." The Sensor says "here's what that means for the CMDB."

Probe/Sensor Limitations That Led to Patterns

• Probes are JavaScript — customizing them requires scripting skills
• When a new OS version ships with different command output formats, the sensor breaks
• No built-in version detection — a probe for RHEL 7 might not work for RHEL 9
• Probes run sequentially — poor parallelism for large environments
• Hard to extend for complex multi-step data collection flows

Discovery Patterns — The Modern Approach

Discovery Patterns are the modern replacement for most probe/sensor pairs. Introduced in Helsinki (2016) and significantly matured since, Patterns use a declarative, step-based approach rather than custom JavaScript.

What Makes Patterns Different

• Declarative steps, not scripts: Patterns are built as a sequence of named steps (Connect, Get OS Info, Run Command, Parse Output, Set CI Field). Each step uses configuration, not code.
• Version-aware: Patterns can include conditions ("if OS version > 7, use this command; else use that command"). This handles OS version differences cleanly.
• Pattern Designer UI: Patterns can be viewed and modified in ServiceNow's Pattern Designer — a visual editor, not a code editor.
• ServiceNow-maintained: ServiceNow ships and updates patterns for common CI types (Linux, Windows, Cisco, VMware, etc.). You receive pattern updates automatically, unlike probes which require manual script maintenance.
• Better performance: Patterns use a more efficient execution engine and better parallelism.

Pattern Components

Pattern Execution Flow

Credential Types — What Discovery Uses to Authenticate

Vertical Discovery must authenticate to each target device. Credentials are stored in ServiceNow's Credential Vault (the discovery_credential table) and retrieved by the MID Server at scan time. Never stored in config.xml or in probe scripts.

Credential Types by Protocol

Credential Affinity — How Discovery Picks the Right Credential

You might have 50 different SSH credentials for different server groups. How does Discovery know which credential to use for which server? The answer is Credential Affinity.

Credential Selection Methods

ServiceNow tries credentials in this order:

1. Credential Affinity (most specific first): A credential can be explicitly assigned to a specific IP address, IP range, or CI record. When a match is found, this credential is tried first.
2. Type-based fallback: If no affinity match is found, Discovery tries all credentials of the matching type (e.g., all SSH credentials) in order until one succeeds.
3. Failure: If no credential succeeds, vertical Discovery fails for that device. The CI gets a partial record with only IP-level data.

Credential Affinity Configuration

On each Credential record, you can specify:

• IP ranges: This credential only applies to 10.0.1.0/24 (the production Linux servers)
• CI class: This credential applies to all cmdb_ci_linux_server CIs
• MID Server: This credential is available only to specific MID Servers

Least-Privilege Principle for Discovery Credentials

Discovery credentials should use read-only accounts where possible:

• Linux: create a dedicated user with sudo access to specific read-only commands only (no full sudo)
• Windows: use a domain user in the "Read-Only" or specific WMI groups, not a Domain Admin
• SNMP: use read-only community strings, never read-write
• Databases: SELECT-only permissions; no INSERT/UPDATE/DELETE

Protocol Deep Dives — SSH, WMI, and SNMP

Understanding what each protocol can discover helps you answer "which credential type is needed for which CI class?" questions.

SSH — Linux and Unix Discovery

SSH is the primary protocol for discovering Linux, Unix, Mac OS X, and network devices that support SSH (Cisco IOS, Junos, etc.).

What Discovery collects via SSH:

• OS name, version, kernel version (uname -a, /etc/os-release)
• CPU model, count (/proc/cpuinfo)
• Memory total and available (/proc/meminfo)
• Disk partitions and usage (df -h, lsblk)
• Network interfaces and IPs (ip addr)
• Running services (systemctl list-units --state=running)
• Installed packages (rpm -qa on RHEL, dpkg -l on Debian)
• Running processes (ps -ef)

SSH Private Key vs. Password: Private key authentication is more secure and is preferred for production. The key must be added to the target server's ~/.ssh/authorized_keys for the Discovery user.

WMI — Windows Discovery

Windows Management Instrumentation (WMI) is Microsoft's remote management protocol. Discovery uses WMI (via DCOM/RPC, port 135 + dynamic high ports) to query Windows systems.

WMI classes Discovery queries:

• Win32_OperatingSystem — OS name, version, build number, last boot time
• Win32_Processor — CPU model, cores, speed
• Win32_ComputerSystem — Total RAM, domain name, hostname
• Win32_LogicalDisk — Drive letters, capacity, free space
• Win32_NetworkAdapterConfiguration — IP addresses, MAC addresses
• Win32_Product — Installed software (MSI-installed only)
• Win32_Service — Windows services and their status

SNMP — Network Device Discovery

Simple Network Management Protocol is used for discovering routers, switches, firewalls, printers, and other network-attached devices that don't support SSH or WMI.

SNMP uses a hierarchical tree of data called a MIB (Management Information Base). Discovery queries specific OIDs (Object Identifiers) to get device properties.

• sysDescr — Device description (make, model, OS version)
• sysName — Hostname
• ifDescr — Interface names and types
• ifOperStatus — Interface operational status (up/down)
• Cisco-specific MIBs — For detailed Cisco device data

SNMP v2c uses a community string (like a password). "public" is the default community string on many devices — this is a security risk and should be changed.

SNMP v3 adds proper authentication (SHA/MD5) and privacy/encryption (AES/DES). Preferred for production.

Pattern vs. Probe — Full Comparison

Custom Patterns — Extending Discovery for Proprietary Systems

ServiceNow ships patterns for common CI types, but your environment may have proprietary applications or custom software that needs custom discovery logic. ServiceNow's Pattern Designer allows you to create custom patterns.

When to Create a Custom Pattern

• A proprietary application runs on discovered servers and you need to track its version and config
• An industry-specific system (medical device software, industrial control software) has no ServiceNow-provided pattern
• You need to discover specific configuration files or registry keys that standard patterns don't capture

Pattern Designer

Navigate to Discovery → Pattern Designer to create or modify patterns. The designer provides:

• Visual step builder (add/remove/reorder steps)
• Step library with pre-built operations
• Test mode to run the pattern against a specific CI and see output
• Version history for pattern changes

Pattern Lifecycle

• Active patterns are used by Discovery when they match a device type
• Retired patterns are kept for history but no longer executed
• When ServiceNow ships an updated version of a pattern (e.g., updated Linux pattern for RHEL 9), it replaces the old version automatically if you haven't customized it. Custom patterns are protected.

Practice Questions

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