ServiceNow Discovery Best Practices

Discovery is the process that probes infrastructure and writes what it finds into the CMDB. This page covers the planning, credentials, rules, reconciliation and rediscovery practices that keep that data accurate once the estate starts to change.

Plan Before You Probe: Credentialing and Scope

The first and most critical practice is planning the discovery scope before running probes. Determine what you want to discover: all infrastructure in a data center, cloud resources across specific accounts, specific operating systems or applications, or particular service components. Scope too wide and discovery takes months and resource; scope too narrow and you miss dependencies.

Document the IP ranges, cloud accounts, or network segments to be discovered. Set up the necessary credentials before starting probes: domain accounts for Windows discovery, SSH keys for Linux, cloud API keys for cloud platforms. Test credentials against target systems to ensure they work before running discovery at scale. Failed credentials cause discovery to fail silently, leading to incomplete data and hours spent troubleshooting why certain systems were not found.

Align discovery with your network architecture: if you have multiple network segments or cloud regions, plan phased discovery by segment. This prevents discovery storms that consume network bandwidth and affect production systems. Run discovery during maintenance windows or off-peak hours to minimize impact on production systems.

Use Conditional Rules to Focus Data Collection

Discovery can collect a vast amount of data—every package, process, user, and configuration detail on a system. Not all of it is useful for your CMDB. Conditional discovery rules are patterns that decide what to collect based on system characteristics: for example, collect software licenses only for systems running enterprise applications, collect detailed network configuration for routers but not for desktops.

Start with basic discovery (OS, hardware, IP) on all systems, then apply conditional rules to collect additional detail only where relevant. This reduces data volume, speeds discovery, and makes CMDB maintenance easier. Document your conditional rules and review them quarterly: as your infrastructure evolves, some rules may become outdated or new rules may be needed.

Validate Against Known Infrastructure Before Promoting

Before promoting discovered data into your live CMDB, validate it against known infrastructure. Do discovered devices match a list of expected systems? Are there discovered systems you did not expect? Are expected systems missing? This validation step prevents inaccurate data from polluting the CMDB.

Run reports comparing discovered systems against infrastructure lists maintained by teams: expected servers from operations, expected cloud resources from infrastructure-as-code repositories, expected applications from the application portfolio. Mismatches are investigated: undiscovered systems might be isolated or off-network; unexpected discovered systems might be shadow IT or misconfigured resources.

This validation is painstaking but critical. Time spent validating discovered data prevents months of working with inaccurate CMDB data.

Deduplicate and Reconcile Overlapping Discovery

If you discover the same infrastructure via multiple methods—network discovery finding a device, cloud discovery finding a virtual machine, application-centric discovery finding a service instance—you get duplicate records unless you deduplicate and reconcile. Discovery includes reconciliation rules: patterns that identify the same physical asset described by multiple probe results and merge them into a single CMDB record.

Out-of-the-box reconciliation rules handle common scenarios, but you may need custom reconciliation for your environment. Test reconciliation rules against a sample of discovered data before running full discovery. Wrong reconciliation rules lead to either duplicates left in place or incorrect merges where two different assets are treated as one.

Schedule Regular Rediscovery and Maintenance Windows

Discovery is not a one-time event. New systems are deployed, old systems are decommissioned, configurations change. Rediscover infrastructure at least quarterly to keep the CMDB current. For rapidly changing environments, monthly or even weekly rediscovery might be appropriate.

Before each rediscovery cycle, communicate with teams: let them know what is being rediscovered and when so they understand if their systems appear or disappear in the CMDB during the cycle. Also run maintenance on the CMDB: identify records that have not been rediscovered in months (they may be decommissioned) and mark them as inactive rather than leaving them in the active inventory.

Monitor Discovery Agent Health and Performance

Discovery is agentless: a MID Server runs each probe against the target systems and returns the output.. Agents consume CPU and network resources. Monitor agent health: are they running, collecting data successfully, or encountering failures? If an agent is failing repeatedly against certain targets, investigate: credentials expired, target system changed, network connectivity lost.

Set up dashboards showing successful and failed discovery runs, the volume of data discovered, and the time required. If discovery time is increasing, it might indicate agent performance degradation or network issues. Address these before they cause discovery cycles to slip.

Govern Discovered Data and Ownership

Once discovered, who maintains that data? For example, if discovery discovers a server, who is responsible for updating the server record if configurations change? Some organizations assign ownership by domain (a system team owns all discovered servers in their domain) or by system type (a platform team owns all discovered databases).

Governance prevents the scenario where discovered data is never updated and becomes stale. Assign clear ownership, establish SLAs for data quality, and hold teams accountable. Teams responsible for an infrastructure area should be responsible for keeping discovery data accurate.

Practices that look fine on the first run and fail on the second

Most discovery practices are judged by the first run, when everything is new and the team is watching. The failures that matter tend to arrive on the second or third cycle, when a credential has rotated, a subnet has been added, a cloud tag has changed or a probe has been moved without anyone updating the scope. This section is about those later failures. It is written for the platform owner who has already completed a first pass and now needs practices that hold up once the estate keeps changing.

The table lists practices that are sound on day one but need a specific check at the second cycle. Each row gives the symptom to expect, so that the team can recognize it when it appears rather than discovering it through a stale report.

A checklist for any change to discovery scope

1. State the change in one sentence: which segment, account or item class is being added, removed or modified.
2. Name the owner who asked for it and the owner who will receive its results.
3. Confirm that access for the change has been approved and tested on one system before the wider scan runs.
4. Run the change against a single segment and inspect the output against the owner’s list for that segment.
5. Check whether any existing records now have a second source, and decide the reconciliation outcome before the next full cycle.
6. Record the change, its test result and its effective date, so that a later reviewer can trace how the current scope came about.

What to watch in the weeks after a change

After a scope change, the first signal is usually a rise in new items or a rise in duplicates. Both are expected for a short period, but they should level off as the new source converges with the existing records. A rise that continues beyond the first cycle means the change has created a second record for each item rather than linking to the first, and that needs fixing before more scope is added. Track the trend for the segment you changed, not only for the whole estate, so the source of the change is clear.

Probe health deserves the same attention. A probe that was healthy under the old scope can struggle with a larger target list, and the symptom is often slower runs rather than errors. Slower runs are an early warning. Investigate them before they start overlapping with other scheduled work.

How often should discovery scope be reviewed against the network allocation record?

Align the review with the cadence at which the network team changes its allocations. Where that cadence is unknown, ask the network team once and record the answer, because the discovery review is only as current as the information it draws on.

Do we need to keep a second set of probes for rehearsing changes?

Not necessarily. A test segment or a small test account, scanned with the same configuration, gives most of the value. A second full set of probes is worth it only when the estate is large enough that a rehearsal cannot represent the production load.

What if a scan completes but a segment returns noticeably fewer items than before?

Treat it as a finding to explain before treating it as good news. Check whether credentials, network reachability or the target list changed, and whether the owner expects fewer items. A drop that nobody can explain is a reason to hold the segment’s output in staging.

Should discovery ever deactivate records automatically?

Only with a reachability check and an owner confirmation step. Automatic deactivation based on age alone is a common way a live system disappears from the model.

Who should be told when a credential rotation is planned?

The discovery owner, and the team that holds the credential. Rotation is often planned for security reasons, and the discovery team can learn about it only when the first scan fails, which is the outcome this checklist is meant to prevent.

When a second cycle exposes duplicates, the duplicate control note is the one to read, and the CMDB best practices guide covers the wider practices those rules sit within. Probe-specific checks are in the MID Server best practices. The optimization and enhancement service page describes how a running instance is reviewed for improvement.