Common ServiceNow Discovery Mistakes and How to Avoid Them

Discovery mistakes are recurring setup and governance errors that leave the CMDB with duplicate, sparse or conflicting configuration items. Each one has a symptom, a root cause and a fix, covering unclear scope, credential gaps, unreconciled data sources, segmentation and access policy, CMDB design and post-scan validation.

Mistake 1: Discovering Too Broadly Without Clear Scope

Symptom: The discovery process runs slowly, creating duplicate or conflicting CIs in the CMDB. Teams struggle to use the CMDB because they cannot find what they are looking for amid duplicates and conflicting versions of the same infrastructure.

Root cause: Discovery is configured without clear rules about what should be discovered, what credentials to use, and how to deduplicate across different discovery sources. A discovery run discovers the same server via multiple methods (SNMP, SSH, DNS), creating separate CIs instead of linking them to one canonical record.

Fix: Define discovery scope clearly: which networks will be discovered, which tools and protocols will be used, which systems are intentionally excluded (development, test, lab systems). Configure deduplication rules so that discovery links related CIs rather than creating duplicates. Run discovery on a test CMDB first to verify behavior before applying to production.

Prevention: Establish a discovery governance process that defines what will be discovered and how. Document deduplication rules and update them when discovery patterns change. Assign someone to review discovery results monthly and correct conflicts before they propagate through dependent processes.

Mistake 2: Poor Credential Management Leaves Systems Undiscovered

Symptom: Some infrastructure is discovered (servers appear in the CMDB), but details are sparse (no OS version, no installed software, no network information). Other infrastructure does not appear at all because discovery lacks access.

Root cause: Discovery relies on credentials (SNMP community strings, SSH keys, WMI accounts) to read device configuration and inventory. If credentials are missing, expired, or incorrect, discovery cannot access the device. Managing credentials across diverse infrastructure is complex, and many teams do not maintain a comprehensive credential registry for discovery.

Fix: Build a credential registry that tracks which credentials are needed for each system or subnet, who owns updating them (network team, server team), and when they expire. Use a credential vault so that discovery jobs have access without embedding credentials in scripts. Test credentials regularly to catch expiration before discovery fails.

Prevention: Assign responsibility for maintaining discovery credentials to the team that manages those systems. Include credential renewal in change management so that when credentials are changed for operational reasons, the discovery credentials are updated simultaneously. Automate credential testing as part of discovery scheduling.

Mistake 3: Not Reconciling Multiple Data Sources

Symptom: Your CMDB contains infrastructure discovered from three different sources (SNMP network discovery, VMware vCenter API, cloud platform API), and they show conflicting information. A server might have three different CI records from three sources, or different data values in overlapping records.

Root cause: Discovery tools pull data independently without coordination. When the same asset is visible to multiple discovery sources, each creates its own CI unless explicit reconciliation rules link them. Reconciliation rules are not configured because they require deep knowledge of both discovery tools and your infrastructure.

Fix: Create a reconciliation strategy that identifies which data source is authoritative for different CI attributes. For example, VMware vCenter is authoritative for virtual machine state and resource allocation, while the cloud platform API is authoritative for cloud instance IDs. Configure discovery reconciliation rules that link CIs based on unique identifiers (hostname, IP, serial number) and update fields based on source priority.

Prevention: Plan discovery sources across all sources. Understand what each source can discover and how they overlap before enabling multiple discovery methods. Document source priority and reconciliation rules so that new team members understand why certain CIs are linked and which data is trusted.

Mistake 4: Ignoring Network Segmentation and Access Policies

Symptom: Discovery finds infrastructure on some network segments but not others. Your CMDB is incomplete because discovery jobs cannot reach systems on restricted networks (development labs, PCI compliance networks, isolated test environments).

Root cause: Network segmentation, firewall rules, and access control policies prevent discovery probes from reaching all infrastructure. Discovery jobs are configured for the main network but lack credentials or network access to reach systems on isolated or restricted segments. Teams assume that incompleteness is acceptable rather than establishing discovery access.

Fix: Map network segments and identify which ones require discovery access. Work with network and security teams to allow discovery probes from designated sources to reach those segments. For highly restricted networks (air-gapped systems, production-only networks), use agentless discovery from a jump host within the segment, or install a local discovery probe on the segment itself.

Prevention: Include discovery access requirements in network and security design. When creating a new network segment or applying security controls, specifically address whether discovery will be allowed and how. Regular audits should verify that discovery still has access to all intended segments.

Mistake 5: CMDB Design Does Not Match Infrastructure Reality

Symptom: Discovery populates the CMDB, but fields are often empty, conflicting, or mismatched to your actual infrastructure. Queries built on CMDB data return incomplete results because key attributes are not filled in reliably.

Root cause: The CMDB CI model was designed without input from the teams who operate the infrastructure. Discovered attributes do not map to fields in the data model, or the data model requires fields that cannot be discovered automatically (business owner, cost centre). Mandatory fields in the CMDB model cannot be populated by discovery, so CIs remain incomplete.

Fix: Redesign the CMDB data model to include only attributes that discovery can populate, plus a minimal set of mandatory attributes that must be enriched manually. Use discovery data to populate CI relationships and discovered attributes; reserve other attributes for manual maintenance by process owners. Make discovery required to populate only high-value attributes; leave others optional.

Prevention: Before deploying discovery, involve infrastructure teams in designing the CMDB model. Validate that key attributes can be discovered or can be maintained reliably by assigned owners. Run a pilot discovery and review data completeness before scaling.

Mistake 6: Insufficient Data Validation After Discovery

Symptom: Discovery runs successfully and populates the CMDB, but no one validates the results. Invalid CIs go undetected: servers marked with wrong OS, network devices with duplicate IP addresses, applications linked to wrong servers.

Root cause: Validation requires manual review or sophisticated automated checks that most teams do not implement. Discovery is treated as a hands-off process: run it, import the results, done. Validation is deferred or skipped because it seems like additional work.

Fix: Build automated data quality checks into the discovery process. Check for obvious errors: CIs with missing critical attributes, duplicate IP addresses, servers with duplicate hostnames, relationships that do not make sense (two database servers with the same name). Flag errors for manual review rather than silently importing bad data. Require sign-off from infrastructure owners before committing discovered data to production CMDB.

Prevention: Make data validation a named step in the discovery process with assigned responsibility. Run discovery on a staging CMDB first where validation happens before results are promoted to production. Include data quality metrics in discovery reporting so trends are visible to leadership.

Checks to run after a scan reports success

A discovery run that finishes without errors tells you the scan ran. It does not tell you the data is right. Many of the expensive problems in a Discovery program are found only after a team has relied on a record for a week. The checks below are for the infrastructure engineer who has just seen a green run and needs to decide whether to trust the output before anything downstream reads it.

Run them against one network segment or one cloud account at a time. A check that passes for a single segment tells you little about the others, and it is much easier to read a small result set than a large one.

Four questions to answer from the run output

An ordered response when the checks disagree with the run

1. Stop promoting data from this run. Leave the output in its staging state, so that nothing downstream reads it while you investigate.
2. Take the systems that are missing and confirm whether each one was attempted. An attempt that failed is an access problem; no attempt is a scope problem.
3. For the unexpected systems, identify which probe found each one, and whether the probe’s scope covers that address range.
4. Fix the cause at its source, whether that is an access request, a scope definition or a probe setting, and note the change in the segment’s record.
5. Rerun against the same segment and compare the new output with the previous run, not with your memory of it.

Why a clean run can still hide a problem

A run can look complete because it returned a healthy number of items while quietly missing a subnet that is hard to reach. Count coverage by segment, not by total. A total that is stable from one run to the next can conceal one segment that has stopped reporting and another that has grown to compensate. Looking at the segments separately is the only way to see that.

The other trap is treating a duplicate as harmless because the record count looks reasonable. Duplicates do not stay still. They are picked up by the next report, the next impact calculation and the next person who edits one of the copies and not the other. Resolve them when you find them, while you still know which probe created each copy.

How many runs do I need before I trust a segment?

There is no universal number. Trust a segment when repeated runs return the same items for the same systems, and when the differences between runs can each be explained. Consistency with an unexplained difference is weaker evidence than a single run you have fully checked.

Should I compare against the CMDB or against the owner’s list?

Against the owner’s list. The CMDB is the thing under test, so comparing against it only shows that the run agrees with itself. The owner’s list is independent, even if it is out of date, and differences from it are what you need to explain.

Can I skip these checks for a cloud account?

Not safely. Cloud accounts change faster than most networks, and a run that succeeds against a stale set of resources can look healthy for a long time. The same four questions apply, although the owner’s list may come from infrastructure-as-code rather than a spreadsheet.

What if the owner’s list is wrong?

That is a valuable result. Record the disagreement, correct whichever side is wrong, and treat the list as a living input rather than a fixed reference.

Before running these checks, confirm the scope and reach that the discovery best practices describe. Where a missing system traces back to a credential problem, the credential governance guide is the place to look at how credentials are controlled, and the Discovery troubleshooting guide is the place to look for next diagnostic steps. If the probe itself appears to be the problem, the MID Server troubleshooting guide is the place to continue.