ServiceNow Discovery Implementation

This guide shows the order of a Discovery implementation: planning which MID Servers to deploy, placing them, configuring patterns, testing and then rolling out. The result is a Discovery system that populates the CMDB and keeps it current as infrastructure changes.

What a Discovery Implementation Engagement Covers

A Discovery implementation engages your organisation to configure the Discovery platform, deploy MID Servers into your network, and establish discovery patterns that detect hardware, software, running services, and relationships between infrastructure components. The engagement typically includes planning which discovery probes to deploy, where to place them, what to discover, and how often to run discovery. It covers configuration of discovery patterns for your platforms: Windows, Linux, network devices, databases, and any custom systems you run. The deliverable is an operational discovery system that automatically populates your configuration management database (CMDB) and keeps it fresh as your infrastructure changes.

The rest of this page follows the engagement in order: the phased approach from planning through probe placement, pattern configuration, testing and production rollout; the deliverables; how Discovery feeds the CMDB and the modules that depend on it; dependencies and sequencing; the implementation mistakes that recur; where to place probes before the first scan; a go-live sequence that catches connectivity faults early; and when an implementation should pause.

Implementation Approach

A typical phased approach starts with discovery planning. You define which infrastructure you will discover, which discovery probes are required, and where to deploy them. This is followed by probe deployment and networking configuration. Network teams ensure that probes can reach discovery targets, and firewalls are opened if needed. In the configuration phase, discovery patterns are created or customised to match your platforms. Testing comes next: run discovery against representative systems, validate that results are accurate, and refine patterns if needed. Finally, production rollout triggers discovery across your estate, and ongoing monitoring ensures probes stay healthy and discovery patterns remain effective as your infrastructure evolves.

Deliverables

The core deliverable is an operational discovery system: probes deployed and healthy, patterns created and tested, and discovery running on schedule. You also receive documentation of the discovery configuration, a runbook for probe troubleshooting, and a knowledge base of patterns and customisations specific to your environment. Many organisations receive training for their operations team so they can troubleshoot probe issues and adjust discovery patterns over time.

How Discovery Connects to Adjacent Modules

Discovery feeds the CMDB, which is the foundation for all downstream processes. Service Mapping builds dependency maps from discovered relationships. Incident Management uses CMDB data to show which services are affected when a CI (configuration item) fails. Change Management uses CMDB impact analysis to assess the risk of a proposed change. Asset Management uses discovered software to track licenses and flag compliance issues. Strong discovery strengthens all downstream processes.

Dependencies and Sequencing

Discovery requires network access to discovery targets. If your network is highly segmented, you may need multiple probes and complex firewall rules. This is typically one of the first dependencies to resolve. A second dependency is a target CMDB schema: discovery writes to the CMDB, which must be designed to store discovered data. If your CMDB is not yet designed or is used by other processes with conflicting structures, align on the schema before discovery starts. A third dependency is network and systems teams: they must support probe deployment and network access. Engage them early.

In terms of sequencing, most organisations implement Discovery after establishing the CMDB but before implementing Service Mapping or Incident Management. If you have a working CMDB from another tool, you may migrate that data into ServiceNow first, then let Discovery handle updates going forward. Do not wait for Discovery to be perfect before using the CMDB; an eighty accurate, automatically-maintained CMDB is more valuable than a most accurate, manually-maintained list that becomes stale.

Common Implementation Mistakes

Deploying probes without testing network connectivity causes discovery to fail silently. Test probe-to-target connectivity before relying on discovery results. Trying to discover too much at once—every system, every attribute, every hour—overloads the network and produces incomplete results. Start narrow: discover critical infrastructure first, refine patterns, then expand. Not defining success criteria upfront leads to vague expectations. Agree on what percentage of infrastructure must be discovered, what accuracy threshold you accept, and how you will measure refresh frequency.

Key Questions for Your Team

What infrastructure must be discovered—hardware, software, services, custom applications? Which are not discoverable and must be manually maintained or imported? Which discovery probes are needed, and where must they be deployed? What discovery patterns exist for your platforms, and which need customisation? How often should discovery run? Who owns discovery configuration changes? What is your escalation path if discovery fails?

Discovery Customisation for Your Infrastructure

While ServiceNow provides discovery patterns for common platforms, your infrastructure likely has unique systems or configurations. Custom discovery patterns may be needed. ServiceNow supports writing custom discovery patterns for proprietary systems or special configurations. Plan for custom work if you have systems that standard patterns cannot discover. Budget time and resources for custom development and testing. Well-designed custom patterns pay for themselves by automating discovery of systems you might otherwise maintain manually.

Placing probes around the network before the first scan runs

Probe placement decides what discovery can see, and it is the step most often decided by whoever happens to have a spare server. A MID Server on the wrong side of a firewall will report a few hosts and quietly miss the rest, and the first dashboard will look reasonable enough to hide the gap. Before any probe is installed, the implementation team should draw the network zones that the discovery targets sit in, mark which zones a single probe can reach, and note which zones need their own probe or a rule change. That drawing is often a short exercise with the network team, and it can save weeks of confusion later.

Placement also depends on the credentials each zone will use. A probe that can reach a zone but lacks the account to log in to its hosts will produce a list of devices with no detail, which looks like discovery working until someone asks for the software inventory.

Placement patterns and when each one earns its keep

A go-live sequence that catches connectivity faults early

Connectivity faults are cheap to fix before discovery is trusted and expensive to diagnose after. The sequence below front-loads the tests that fail silently.

1. Test the path from each probe to a representative target in every zone, separately for each protocol the patterns will use.
2. Run discovery against a small, known set of hosts whose configuration you can check by hand, and compare what was found with the real state.
3. Review the patterns that matched and the ones that did not. A pattern that never matches is usually a missing credential or a version it does not recognize, not a sign that the software is absent.
4. Confirm that the schedule for the production run will not overlap with backups or patch windows that load the same network.
5. Agree who receives an alert when a probe stops, and what the response is, before the first production cycle starts.
6. Record the probe list, credentials owners and schedule in the implementation documentation that the operations team will inherit.

What goes wrong once the first production cycle lands

Most of the trouble that teams report in the first month does not come from the scan itself. It comes from data arriving at the CMDB with the wrong shape. Discovery may write items under a class that the existing CMDB model does not use, which makes reporting look empty for those items. Relationships may be created between items that were never meant to link, because two naming conventions meet. Another common problem is an initial run so large that it floods the change queue with new items, and the team cannot review them before the next run changes them again. Limit the first production run to a subset of targets, review the resulting items against the schema, and widen the scope once the pattern of results is understood.

When implementation should pause

Stop before production if the CMDB schema is still being argued over. Discovery writes to whatever structure exists, and changing the structure later means reprocessing a large volume of items. A pause is also sensible if the network team cannot commit to opening the required paths within the timeframe of the project. Partial access leads to partial data, and partial data tends to be accepted as complete because nothing looks obviously wrong. A third reason to pause is an absence of anyone who will read the alerts. An alert no one reads is a silent failure with a schedule attached.

Do we need a probe in every data center?

Not necessarily. A probe is needed where a zone cannot be reached from elsewhere under the access rules that apply. If the rules allow a central probe to reach the zone safely, one probe may be enough. The test is whether the probe can reach the targets in that zone reliably, not whether a data center exists.

What credentials should the probe use?

Use dedicated, scoped accounts with the minimum rights needed for the patterns in use, stored where the probe can read them and the wider team cannot. Shared administrator accounts make audit trails meaningless and tend to be the first thing a security review flags.

How do we know the patterns cover our software?

Compare a list of installed products taken from a trusted source, such as the software license register, against what discovery identifies on a sample of hosts. Gaps in that comparison show which patterns need custom work or which products need manual records.

Should we import the existing CMDB before discovery starts?

Often yes, if the existing data is reasonably current, because discovery then updates records rather than creating a second set. If the existing data is mostly stale, importing it can preserve errors that discovery would otherwise correct. Decide based on a sample check, and keep the import log so the origin of each record is known.

The discovery credential governance article covers how discovery access is scoped, owned and reviewed, and the discovery consulting service describes the scope decisions that should come first.