Discovery

What It Is

Discovery in ServiceNow is an automated infrastructure scanning system that probes your network to identify devices, applications, and services, then creates corresponding Configuration Items (CIs) in the CMDB. Unlike generic network discovery tools that simply map topology, ServiceNow Discovery is specifically designed to populate a service-oriented configuration database with rich relationship data. It operates through MID Servers deployed in your network segments, which execute targeted probes and sensors to gather detailed configuration information from discovered assets.

Architecturally, Discovery sits at the foundation of the ITOM stack, serving as the primary data ingestion engine for the entire IT Operations Management suite. It feeds the CMDB, which in turn enables Service Mapping, Event Management, Orchestration, and Cloud Management capabilities. The platform treats Discovery as a first-class citizen in the data flow architecture — it's not an add-on tool but a core component that determines the quality and completeness of every downstream ITOM process. The discovery_status table tracks every discovery attempt, while specialized CI tables like cmdb_ci_server and cmdb_ci_network_gear store the results with full audit trails of when and how each piece of data was discovered.

The business function Discovery serves is eliminating the chronic problem of CMDB staleness that plagues most enterprise IT organizations. Traditional approaches to maintaining configuration data — manual entry, periodic audits, change-driven updates — inevitably fall behind the pace of infrastructure evolution. Discovery transforms the CMDB from a static inventory into a living reflection of your actual environment. This accuracy enables reliable impact analysis during incidents, precise change planning, and trustworthy service dependency mapping. Without accurate discovery data, IT teams make decisions based on outdated assumptions about what's running where, leading to extended outages and failed changes.

ServiceNow designed Discovery around the recognition that enterprise networks are heterogeneous, segmented, and constantly changing. Rather than building a centralized scanner that would struggle with firewalls and network boundaries, they created the MID Server architecture where lightweight agents deployed in each network segment perform the actual discovery work. This distributed approach allows Discovery to reach into DMZs, private clouds, and segmented environments while maintaining security boundaries. The probe and sensor framework provides extensibility — each device type gets specialized logic for extracting the most relevant configuration details, rather than generic SNMP polling that misses critical relationships.

Multiple personas interact with Discovery in fundamentally different ways. CMDB managers configure discovery schedules, define IP ranges, and tune identification rules to ensure clean data ingestion without duplicates. Network operations teams consume discovery results to understand topology and troubleshoot connectivity issues. ITOM architects use discovery data to design service maps and define monitoring policies. Application teams rely on discovery to understand infrastructure dependencies when planning deployments. Developers extend discovery capability by writing custom probes for proprietary systems or cloud services. Each group needs different levels of detail — ops teams want comprehensive network topology while security teams focus on software versions and patch levels.

Without Discovery, the ServiceNow ITOM suite becomes largely theoretical. Service Mapping would have no infrastructure data to map relationships. Event Management would lack context about which systems generate which events. Change Management would operate without reliable dependency information for impact analysis. The CMDB would degrade into a manually-maintained spreadsheet with all the accuracy problems that entails. Cloud Management would be blind to actual cloud resource utilization versus what's provisioned. Discovery isn't just a nice-to-have data collection tool — it's the sensory system that makes intelligent IT operations possible.

Where It Fits in the Platform

Discovery operates as the primary data ingestion engine for ServiceNow's IT Operations Management suite, sitting between your infrastructure and the CMDB. It's tightly integrated with the platform's data architecture — discovery results flow through transform maps and identification rules before becoming CIs, ensuring data quality and preventing duplicates. The MID Server framework that powers Discovery also serves Event Management, Orchestration, and Cloud Management, making it a shared infrastructure component across ITOM applications.

The platform treats Discovery as an authoritative data source, meaning it can create, update, and even delete CIs based on what it finds or doesn't find in your environment. This positioning gives Discovery significant power in the overall data model — it's not just populating empty fields but actively maintaining the accuracy of your configuration database. Discovery also feeds directly into ServiceNow's machine learning capabilities, providing the historical data patterns that enable predictive analytics and anomaly detection in other ITOM modules.

Key Relationships:

• CMDB: Discovery populates and maintains configuration items through automated scanning, serving as the primary data source for infrastructure CIs. Without Discovery, the CMDB relies entirely on manual entry or integrations.
• Service Mapping: Uses Discovery's CI data and relationship information to automatically build service topology maps. Discovery provides the foundational infrastructure layer that Service Mapping builds application services on top of.
• MID Server: Discovery runs entirely through MID Server probes and sensors, making it completely dependent on MID Server infrastructure. Each MID Server can execute multiple discovery schedules and probe types simultaneously.
• Event Management: Discovery provides the CI context that allows Event Management to correlate alerts with specific infrastructure components. Events without CI context become much harder to route and prioritize effectively.
• Cloud Management: Shares the MID Server infrastructure and extends Discovery concepts to cloud resources like AWS EC2 instances and Azure VMs. Cloud Discovery follows the same probe-based architecture but targets cloud APIs instead of network protocols.
• Asset Management: Discovery data feeds into hardware asset records, providing automated inventory updates and lifecycle tracking. The discovered hardware specifications help drive procurement and refresh planning decisions.

How You Encounter This in Practice

The CMDB Manager Debugging Missing CIs

You're the CMDB manager and the network team reports that several critical servers aren't showing up in Service Map even though they're definitely running in production. You check the CMDB and find no CIs for these servers, but you know Discovery runs nightly on that subnet. Looking at the discovery_status table, you see the discovery schedule completed successfully but with warnings about authentication failures. Drilling into the detailed logs reveals that the service account passwords expired last month, so Discovery can see the servers via ping but can't gather detailed configuration data to create proper CIs.

Understanding Discovery's probe architecture explains why this happens — ping sweeps discover devices but detailed CI creation requires authenticated access to gather the configuration details needed for proper identification and classification. Without that authentication, Discovery creates incomplete records or skips CI creation entirely to avoid polluting the CMDB with low-quality data. Someone who doesn't understand this architecture might assume Discovery isn't working at all, missing the authentication root cause that's actually preventing proper CI population.

The Network Engineer Troubleshooting Duplicate CIs

You're a network engineer who set up Discovery in multiple data centers, and now you're seeing duplicate server CIs in the CMDB — the same physical server appears as two different configuration items with slightly different names and IP addresses. The business is complaining that Service Maps show conflicting information and change management can't accurately assess impact because it doesn't know which CI record is correct. Investigation reveals that Discovery is running from MID Servers in both data centers, and each one is discovering the same multi-homed servers that have IP addresses in both network segments.

Understanding Discovery's identification and reconciliation rules reveals how ServiceNow determines whether a discovered device should create a new CI or update an existing one. The platform uses configurable identification rules that typically compare attributes like MAC addresses, serial numbers, or hostnames to detect duplicates. In this case, the servers appear different because they're discovered from different network perspectives with different primary IP addresses, and the identification rules aren't sophisticated enough to recognize them as the same physical device. Someone without this knowledge might try to manually delete duplicates, missing the underlying configuration issue that will just recreate them on the next discovery run.

The Application Team Planning a Database Migration

You're on an application team planning to migrate a critical database to new hardware, and you need to understand all the systems that will be impacted by the change. The change manager insists on a comprehensive impact analysis, but the application documentation is outdated and doesn't reflect the current deployment architecture. Using Service Map, you can see the database server CI and its relationships, but you notice that some of the connecting applications show as generic cmdb_ci_computer records instead of specific application CIs, making it hard to identify which business services will be affected.

Understanding Discovery's probe coverage reveals why some systems are fully discovered while others appear as generic computer CIs. Discovery has specific probes for common applications like Oracle, SQL Server, and Apache, but custom or proprietary applications might only be detected as running processes without proper CI classification. The depth of discovery data directly impacts the quality of dependency mapping and change impact analysis. Someone who doesn't understand this limitation might trust the Service Map as complete, potentially missing critical dependencies that weren't fully discovered, leading to unexpected application failures during the migration.

What People Get Wrong

This misconception leads to disappointment and failed implementations because Discovery requires extensive upfront configuration to work effectively. You need to define IP ranges, configure credentials for different device types, set up appropriate MID Servers in each network segment, and tune identification rules to prevent duplicates. The out-of-box Discovery configuration is designed for demonstration environments, not production networks with complex segmentation, multiple device types, and security restrictions.

This misunderstanding exists because ServiceNow marketing materials often emphasize the "automated" nature of Discovery without highlighting the significant configuration prerequisites. The platform does automate the scanning and data collection process, but it can't automatically know your network topology, security credentials, or business context. Many organizations launch Discovery without proper planning and then conclude it doesn't work when it fails to discover secured systems or creates low-quality CIs.

In production, this approach results in incomplete CMDB data, missed dependencies in Service Maps, and unreliable change impact analysis. Teams end up manually entering CI data anyway, defeating the purpose of automated discovery. Worse, partially successful discovery creates false confidence — you think you have comprehensive infrastructure data when you actually have significant blind spots that will surface during critical incidents or major changes.

The reality is that successful Discovery implementations require dedicated project planning, coordination with network and security teams to ensure appropriate access, careful credential management, and ongoing tuning of discovery schedules and identification rules. Organizations that treat Discovery as a "turn it on and forget it" solution consistently struggle with data quality and coverage issues.

This assumption leads to over-aggressive discovery schedules that actually degrade data quality and system performance. Running discovery too frequently can overwhelm your network infrastructure, create excessive load on discovered systems, and paradoxically reduce data accuracy due to identification conflicts and timing issues. Discovery generates significant network traffic and system resource consumption on both the MID Servers and target systems — treating it like a real-time monitoring tool will create performance problems.

This misconception exists because people conflate Discovery with monitoring or real-time asset tracking. Discovery is designed for maintaining configuration baselines, not tracking minute-by-minute changes. Most infrastructure configuration data — server hardware specs, installed software versions, network device configurations — changes relatively infrequently, making daily or weekly discovery schedules more appropriate than hourly runs. Frequent discovery can also create race conditions where multiple discovery processes try to update the same CI simultaneously.

In production, excessive discovery frequency leads to network congestion, slower application performance on discovered systems, MID Server resource exhaustion, and database performance issues from constant CI updates. IT teams start receiving complaints about network slowdowns and system responsiveness problems. The CMDB can also become unstable if discovery runs overlap or if rapid updates trigger cascading business rule executions. Organizations often need to scale back their discovery frequency after experiencing these problems, requiring them to rebuild trust with affected teams.

Admin vs Developer Perspective

For Admins

Admins manage Discovery schedules, configure credential records, and troubleshoot failed discovery runs through the discovery_schedule and discovery_status tables. They decide which IP ranges to scan, which probes to enable for different device types, and how to handle identification and classification rules. The admin's primary concern is maintaining credential hygiene—ensuring SSH keys and service accounts don't expire, rotating credentials without breaking discovery, and managing the balance between discovery frequency and system load. When discovery jobs fail or produce incomplete results, admins debug through MID Server logs, probe parameters, and sensor configurations to identify whether the issue is network connectivity, credential problems, or sensor logic failures.

For Developers

Developers extend Discovery by creating custom sensors, probes, and identification rules using the Discovery API and JavaScript patterns. They work primarily with the DiscoveryCMPUtils script include and probe result processing to extract custom attributes from discovered devices. Custom sensors follow the standard pattern of extending base sensor classes, implementing process() methods, and writing results back to the CMDB through the reconciliation engine. Developers also create transform maps for importing discovery results, build custom classification rules through cmdb_ci_class records, and integrate Discovery data with external asset management systems through REST APIs and scheduled jobs.

How It Connects to Other Concepts

• CMDB — Discovery's primary purpose is populating and maintaining CMDB records through automated reconciliation. Every discovery run creates, updates, or marks stale the Configuration Items in tables like cmdb_ci_server, cmdb_ci_network_gear, and cmdb_ci_database based on identification rules and data quality policies.
• MID Server — Discovery cannot function without MID Servers, which execute probes and sensors within customer networks. The MID Server downloads probe definitions from the instance, runs them against target systems, and uploads results back through the ecc_queue table for processing.
• Service Mapping — Discovery provides the foundational CI data that Service Mapping uses to build application service models. Without accurate server, database, and application discovery results in the CMDB, Service Mapping cannot create meaningful business service relationships or dependency maps.
• Event Management — Discovery-populated CMDB records serve as the source of truth for correlating monitoring events to Configuration Items. When monitoring tools send alerts, Event Management uses the CI data from Discovery to determine which server, application, or service is affected.
• Credentials — Discovery depends entirely on credential records in the discovery_credentials table to authenticate against target systems. Each discovery schedule must have appropriate SSH, SNMP, WMI, or database credentials configured, and credential failures are the most common cause of discovery problems.
• Transform Maps — Discovery uses transform maps to process probe results and create or update CMDB records. Each CI class has associated transform maps that define how raw discovery data maps to CMDB fields, applies business logic, and handles data conflicts during reconciliation.

Junior vs Senior Knowledge Gap

Junior administrators treat Discovery as a magic black box—they configure IP ranges and credentials, then expect perfect CMDB population. They typically focus on getting discovery schedules to run successfully without understanding the probe and sensor architecture underneath. When discovery results are incomplete or inaccurate, juniors often add more credentials or expand IP ranges rather than investigating which specific probes are failing and why. They miss that Discovery success isn't measured by job completion, but by CMDB data quality and business relevance. Most critically, juniors don't grasp that Discovery is a reconciliation process—they don't understand how identification rules work, why duplicate CIs appear, or how to tune the matching logic for their environment.

The mental model shift happens when you realize Discovery is fundamentally about data reconciliation, not just data collection. Experienced professionals understand that every discovered device goes through identification, classification, and reconciliation phases—and that tuning these phases is more important than tuning the initial discovery probes. They know that discovery patterns and horizontal patterns are separate concepts, that different sensor types (WMI, SSH, SNMP) provide different data quality levels, and that the reconciliation engine uses complex matching algorithms that can be customized per CI class. Senior admins have learned to read MID Server logs effectively, understand the difference between probe failures and sensor failures, and can troubleshoot credential issues without compromising security.

What never appears in documentation is that Discovery performance and accuracy are inversely related—the more comprehensive you make discovery, the slower it runs and the more false positives you generate. Senior architects know to start with narrow, high-confidence discovery patterns and gradually expand scope rather than trying to discover everything at once. They understand that Discovery's real value comes from maintaining data freshness over time, not from the initial discovery run, so they design schedules around change detection rather than full scans. They also know that Discovery generates massive amounts of log data and can overwhelm both MID Servers and instance performance if not properly throttled and monitored.

Experienced architects ask questions that juniors never consider: How will Discovery handle network segmentation and firewall rules? What's the credential rotation strategy and how will it integrate with enterprise password management? How do we prevent Discovery from interfering with production systems during business hours? What's the data retention strategy for discovery logs and historical CI data? How do we measure Discovery ROI and prove CMDB data quality improvements? They also understand the political and security implications—Discovery requires privileged access to every system in the infrastructure, making it a high-value target for attackers and a sensitive topic with security teams.

Quick Reference

• Discovery schedules in discovery_schedule can only run on one MID Server at a time, but you can create multiple schedules with the same IP range to achieve parallelization.
• The discovery_status table shows high-level job status, but real troubleshooting happens in discovery_log and the MID Server agent logs on the actual server filesystem.
• SSH discovery requires both port 22 access and specific command permissions—many failures happen because service accounts can authenticate but can't run discovery commands like dmidecode or lscpu.
• Identification rules in cmdb_identifier are processed in order by order field value—the first matching rule wins, so more specific rules need lower order numbers than generic ones.
• Discovery creates records with discovery_source populated—manually created CIs should leave this field empty to prevent Discovery from overwriting them.
• The discovery_credentials table encrypts passwords automatically, but credential testing happens from the MID Server, not the instance—network connectivity must exist from MID Server to targets.
• Horizontal discovery patterns run after initial CI creation and can modify existing records—this means the same CI can be updated multiple times during a single discovery run.
• SNMP discovery requires both read community strings and proper OID access—many network devices have custom OIDs that require vendor-specific MIB files on the MID Server.
• Discovery behavior probes in discovery_probes can be customized per discovery schedule, but changes affect all future runs—there's no way to test probe modifications without running them.
• The reconciliation engine can create duplicate CIs if identification rules are too loose or if multiple discovery schedules find the same device with different data—always test identification logic in sub-production first.