Getting Ready for Top-Down Discovery

Will Hallam
ServiceNow Employee

an hour ago

Service Mapping — Top-Down Discovery Readiness Guide

MID Server, Connectivity, and Credential Prerequisites for Top-Down Discovery
Covers: Windows, Linux, Web Servers, App Servers, Databases, Middleware, ERP, Load Balancers, Network Devices
Version 2.1  |  May 2026

⚠️ Important: This is a field-authored readiness guide synthesized from ServiceNow product documentation, pattern source analysis, and implementation experience. It is not official ServiceNow documentation and does not replace the ServiceNow product documentation, KB articles, or guidance from ServiceNow Technical Support.

All port numbers, credentials, minimum privileges, and configuration recommendations should be validated in a non-production environment before deployment to production. Specific requirements may vary by platform release, installed plugin versions, customer security policies, and target application configurations. For the latest authoritative guidance, consult docs.servicenow.com.

Scope — Agentless Top-Down Discovery: This guide covers the prerequisites for agentless top-down discovery, where the MID Server remotely probes targets over the network using WMI, PowerShell, SSH, JDBC, and application-specific protocols. All port, credential, and connectivity requirements described in this document assume this agentless model.

ServiceNow also supports Agent Client Collector (ACC)-based top-down discovery, where a lightweight agent installed on each target host collects data locally and reports back to the instance. The ACC model has a fundamentally different prerequisite profile — it requires agent deployment and lifecycle management rather than network port access and remote credentials, and shifts the trust boundary from the MID Server to the host itself. ACC-based discovery is a large enough topic to warrant its own readiness guide and is not covered here.

Contents

  1. Executive Summary
  2. Tier 1: Universal Prerequisites
  3. Tier 2: Protocol Family Baselines
  4. Tier 3: Stack-Specific Reference Matrix
  5. Common Failure Patterns
  6. Next Steps
  7. Appendix: Official Reference Sources

Executive Summary

ServiceNow Service Mapping builds a relationship-rich topology of your business applications by walking from a defined entry point (URL, hostname, or port) through every layer of the stack: load balancers, web servers, application servers, middleware, and databases. For this to work, three things must be in place before the first scan:

  1. A MID Server positioned with network reachability to every host in the application path
  2. Firewall rules permitting the specific protocols each layer requires
  3. Service account credentials with read-level access at both the operating system and application tiers

This guide is organized in three tiers. Tier 1 covers universal prerequisites that apply to every engagement regardless of stack. Tier 2 covers the two protocol families (Windows and Linux/Unix) that form the baseline for all downstream patterns. Tier 3 is a modular reference matrix covering seventeen common application stacks with their specific port, credential, and CI-class details. Address Tiers 1 and 2 first; then use Tier 3 to add the stack-specific requirements for your environment.

Tier 1: Universal Prerequisites

These requirements apply to every Service Mapping engagement, regardless of what applications are in scope.

How Service Mapping Differs from Discovery

Discovery scans IP ranges and classifies every reachable device. Service Mapping starts from a single entry point (a URL, a hostname:port, or a load balancer VIP) and walks the live application topology by following connections from each discovered component to the next.

Discovery is strongly recommended as a prerequisite. The horizontal patterns (Windows OS, Linux OS) should have already populated the base server CIs that Service Mapping's vertical patterns will attach to. While Service Mapping can trigger horizontal discovery on-the-fly when it encounters an unmapped host, running Discovery first provides more predictable results and cleaner troubleshooting isolation.

Plugin Activation

Confirm the following plugins and store apps are active on your ServiceNow instance:

  • com.snc.discovery — Discovery
  • com.snc.service-mapping — Service Mapping
  • sn_itom_pattern — Discovery and Service Mapping Patterns (store app). Contains the vertical application patterns. Ensure the latest available version is installed via System Applications > All Available Applications > Updates.
  • sn_pattern_design — Visibility Content (store app, required from Tokyo onward). Companion to sn_itom_pattern. Both store apps are required for a complete pattern library.

Entry Point Definition

For each application you want mapped, you must provide an entry point — the front door through which Service Mapping begins its topology walk:

  • URL: https://app.example.com — Service Mapping resolves DNS, connects, and discovers the web/app server behind it.
  • Host + Port: dbserver01.corp.local:1521 — For non-HTTP entry points (database listeners, message queues, etc.).
  • Load Balancer VIP: If traffic enters through an F5, NetScaler, or similar device, provide the VIP. Service Mapping walks through the LB into the backend pool (requires LB credentials).

Gather a list of entry points for each application in scope before the engagement. This is frequently the longest lead-time item.

DNS Resolution

The MID Server must be able to resolve every hostname it encounters during the topology walk — not just the initial entry point, but also backend hostnames referenced in application configuration files, database connection strings, and load balancer pool member definitions. Verify DNS resolution from the MID Server's perspective for both external and internal hostnames.

MID Server Placement and Sizing

The MID Server is the on-premises execution engine. It must reside on a host with routable network access to every host in the application topology — not just the entry point, but every hop the walk will reach.

  • Deploy on Windows Server (2016+) if Windows targets are in scope. WMI and PowerShell probes execute natively on a Windows MID. .NET Framework 3.5 must be installed — it is required for Service Mapping and pattern-based discovery and is not installed by default on Server 2016+.
  • Deploy on Linux if the environment is exclusively Linux/Unix.
  • If targets span multiple network zones or DMZs, deploy one MID Server per zone.
  • The MID Server needs outbound HTTPS (443) to your ServiceNow instance. No inbound rules are required — the MID Server polls.

Sizing (field recommendations for shared Discovery + Service Mapping workloads):

Target Scale CPU RAM Disk
< 1,000 CIs 4 cores 16 GB 50 GB
1,000 – 10,000 CIs 8 cores 16 GB 50 GB
> 10,000 CIs 8+ cores 32 GB 100 GB

Note: These exceed the platform's documented minimums (4 cores / 4 GB RAM / 36 GB disk). The platform minimum is sufficient for light workloads; the figures above reflect real-world sizing for production engagements.

MID Server Validation

After installing the MID Server, navigate to MID Server > Servers, select the MID Server record, and click Validate. The MID must show Up status and pass all validation checks before it can process jobs. Common failures: outbound connectivity blocked by proxy/firewall, Java version mismatch, or insufficient disk space.

Credential Affinity and Ordering

When multiple credential records overlap the same IP ranges, ServiceNow tests them in order. To minimize scan duration and avoid authentication lockouts:

  • Order credentials from most specific to least specific (narrow IP ranges first).
  • Use credential affinity rules: configure on the credential record via the Applies to related list, or under Discovery > Credentials > Credential Affinities.
  • Avoid creating multiple credentials of the same type covering the same targets.

Cloud and Hybrid Considerations

This guide focuses on on-premises top-down discovery. Cloud-hosted tiers (AWS EC2, Azure VMs, GCP Compute Engine) require separate cloud discovery configuration using API credentials (IAM roles, service principals, service accounts). Cloud discovery is configured under Discovery > Cloud Discovery Schedules. For hybrid applications, both configurations must be in place for Service Mapping to walk the complete topology.

Tier 2: Protocol Family Baselines

Service Mapping's vertical patterns all execute after the horizontal OS-level pattern has succeeded. Every engagement starts with getting the OS-level protocol family working. If your environment has both Windows and Linux targets, you need both.

Windows Protocol Family

Covers all Windows Server targets and every application running on Windows (IIS, MSSQL, SharePoint, Exchange, .NET, WebLogic on Windows, etc.).

Protocol Port Direction Purpose
WMI/DCOM 135 MID → Target RPC endpoint mapper. Initial classification handshake.
RPC Dynamic 49152–65535 MID → Target DCOM high ports after 135 handshake. Can be constrained (see below).
SMB 445 MID → Target Registry reads, software enumeration, IIS metabase, config file reads.
WinRM (HTTP) 5985 MID → Target PowerShell remoting. Advanced OS collection and vertical patterns.
WinRM (HTTPS) 5986 MID → Target Encrypted PowerShell remoting. Required when TLS is mandated.

Windows Credential Requirements:

  • Account type: Active Directory domain service account (preferred) or local account.
  • Privilege: Member of local Administrators group. Required for WMI namespace access (root\cimv2, root\default, root\Microsoft\IIS), remote registry reads, and PowerShell remoting.
  • Interactive logon: Not required. Set "Deny log on locally" and "Deny log on through Remote Desktop" for hardening. Discovery authenticates via NTLM/Kerberos network logon (type 3 in Windows security audit logs), not interactive logon.
  • WinRM: Must be enabled on each target (winrm quickconfig). For HTTPS, a valid server certificate must be bound to the WinRM listener.
  • UAC note: Non-built-in local admin accounts are subject to remote UAC token filtering, which silently strips admin privileges. Use a domain account in the local Admins group (exempt from filtering) or set LocalAccountTokenFilterPolicy = 1 on the target.

Constraining DCOM Dynamic Ports: If your security team cannot open the full 49152–65535 range, restrict DCOM on each target via HKLM\SOFTWARE\Microsoft\Rpc\Internet. Set Ports (REG_MULTI_SZ) to your range (e.g., 50000–50100), set PortsInternetAvailable = Y and UseInternetPorts = Y, restart the target, and open only that range.

Linux / Unix Protocol Family

Covers all Linux, AIX, Solaris, and HP-UX targets and every application running on them (Oracle, Tomcat, Apache, SAP, Kafka, PostgreSQL, WebSphere on Linux, etc.).

Protocol Port Direction Purpose
SSH 22 MID → Target OS classification, process enumeration, filesystem reads, all vertical pattern operations.

Linux/Unix Credential Requirements:

  • Account type: Named service account with SSH key-based authentication (preferred) or password.
  • Privilege: sudo access to a defined set of commands. Full root is not required. Discovery needs: ps, netstat/ss, cat/head on config files, dmidecode, lsblk/df, and package manager queries. A sudoers entry with NOPASSWD for these commands is sufficient.
  • Shell: bash or sh. Restricted shells (rbash) may block required commands.
  • Key format: RSA or ECDSA. Upload the private key to the ServiceNow credential record; the public key goes in ~/.ssh/authorized_keys on each target.

Tier 3: Stack-Specific Reference Matrix

Once the Tier 2 OS-level baseline is working, add the stack-specific requirements for each application layer. The "Additional Ports" column lists only ports needed beyond the Tier 2 baseline.

Web Servers and Application Servers

Stack OS Additional Ports Additional Credential
IIS Windows None beyond Windows baseline Windows credential (local admin)
Uses WMI (root\Microsoft\IIS namespace). IIS Management Tools Windows feature must be installed on target. No application-level credential needed.
Apache HTTP Linux or Windows None beyond OS baseline SSH or Windows credential (OS-level only)
Reads httpd.conf via filesystem. No application-level credential needed.
Tomcat Linux or Windows HTTP connector (default 8080); AJP 8009 if in use SSH or Windows credential (OS-level only)
Detects via org.apache.catalina.startup.Bootstrap process signature. Reads server.xml via filesystem. No Tomcat manager credential needed.
WebSphere Linux or Windows SOAP connector (default 8880); Admin console (default 9060) SSH or Windows (OS) + WAS admin credential
Process signature: com.ibm.ws.runtime.WsServer. WAS admin credential needed for cell/node/EAR enumeration.
WebLogic Linux or Windows Admin server (default 7001); Node Manager (default 5556) SSH or Windows (OS) + WebLogic admin credential
Process signatures: Dweblogic.Name, weblogic.Server. Admin credential needed for domain/managed server/deployment enumeration.
JBoss / WildFly Linux or Windows Management (default 9990); HTTP (default 8080) SSH or Windows (OS) + JBoss management credential

Databases

Stack OS Additional Ports Additional Credential
Microsoft SQL Server Windows TCP 1433 (default); UDP 1434 (SQL Browser for named instances) Windows (OS) + JDBC credential
Minimum: public + VIEW SERVER STATE + VIEW ANY DEFINITION; db_datareader on master. Named instances may use dynamic ports — see SQL Browser note below.
Oracle Database Linux or Windows TCP 1521 (TNS listener, default) SSH or Windows (OS) + Applicative credential
Applicative credential type in ServiceNow, not JDBC. Listener and instance patterns are separate. See Oracle credential detail below.
PostgreSQL Linux or Windows TCP 5432 (default) SSH or Windows (OS) + JDBC credential
PG 10+: grant pg_read_all_settings and pg_read_all_stats. PG 9.x: grant SELECT on specific pg_catalog views instead.
MySQL / MariaDB Linux or Windows TCP 3306 (default) SSH or Windows (OS) + JDBC credential
SELECT on information_schema and performance_schema. performance_schema needed for replication topology in current pattern versions.
IBM DB2 Linux or Windows TCP 50000 (default) SSH or Windows (OS) + JDBC credential (SYSMON authority)
SYSMON is the minimum for Discovery. Do not use db2 instance owner — it is root-equivalent and unnecessary for read-only discovery.

Oracle Credential Detail

The Oracle credential in ServiceNow is configured as an Applicative credential type (not JDBC — JDBC is used for SQL Server). The Oracle user needs SELECT access to these specific views:

  • V$DATABASE, V$VERSION, V$PARAMETER, V$INSTANCE, V$CONTAINERS — instance identification, version, configuration
  • DBA_FEATURE_USAGE_STATISTICS — edition and feature detection
  • Filesystem read access to tnsnames.ora and oratab (via the OS-level SSH/Windows credential, not the Oracle credential)

As an alternative, SELECT_CATALOG_ROLE covers all of the above but is extremely broad and may be rejected by DBA teams applying CIS benchmark hardening. We recommend the specific views as the primary path.

SQL Server Named Instance Note

Named instances using dynamic port assignment require the SQL Server Browser service (UDP 1434). If Browser is stopped or the port is firewalled, Discovery only finds instances on static ports. Either start the Browser service and open UDP 1434, or assign static ports in SQL Server Configuration Manager.

SAM Pro note: The MSSQL vertical pattern's cpu_sockets field is the sole automated source for per-core license calculations in SAM Pro. Without a working SQL credential, SAM Pro cannot reconcile SQL Server licenses against actual socket/core counts.

Middleware and ERP

Stack OS Additional Ports Additional Credential
IBM MQ Linux or Windows Queue manager listener (default 1414) SSH or Windows (OS) + MQ credential (mqm group)
Discovers queue managers and queues.
Kafka Linux (typical) Broker port (default 9092) SSH credential (OS-level only)
Reads server.properties via filesystem.
SAP (ABAP stack) Linux (typical; Windows supported) RFC 33<NN>, DIAG 32<NN>; HANA SQL 3<NN>15 SSH (OS) + SAP RFC credential (dialog user with S_RFC)
NN = two-digit instance number. Multiple instances = multiple port ranges. One SID can produce 5–10 CIs.

SAP Port Numbering Convention

SAP uses a two-digit instance number (NN) to derive its listening ports. For instance number 00:

  • RFC (Gateway): 33NN → 3300
  • DIAG (SAP GUI): 32NN → 3200
  • HANA SQL: 3NN15 → 30015

For instance number 01, the ports become 3301, 3201, and 30115. A single SAP landscape may have multiple instance numbers across dev/quality/production. Ask your Basis team for the complete list of instance numbers and SIDs before submitting firewall change requests.

Infrastructure

Stack OS Additional Ports Additional Credential
F5 BIG-IP Appliance / Linux iControl REST: TCP 443 SSH (tmsh) + iControl REST credential
Admin or custom role with read access to /mgmt/tm/ltm/ endpoints. The F5 operator role has insufficient privilege for pool member enumeration. LBs are route-through infrastructure, not Business App seeds.
Citrix NetScaler Appliance NITRO API: TCP 443 or 80 SSH + NITRO API credential (nsroot or read-only admin)
Network Devices Various SNMP: UDP 161 SNMP credential (v2c or v3 — see detail below)
Required when topology walk traverses network infrastructure.

SNMP v3 Credential Detail

SNMPv3 has three security levels, each requiring different credential fields in ServiceNow:

  • noAuthNoPriv: Username only. Rarely used in enterprise environments.
  • authNoPriv: Username + authentication protocol (MD5 or SHA) + authentication passphrase.
  • authPriv: Username + auth protocol + auth passphrase + privacy protocol (DES or AES) + privacy passphrase. This is the most common enterprise configuration.

All fields must match the device's SNMPv3 user configuration exactly. A mismatch on any field causes a silent authentication failure.

Common Failure Patterns Across All Stacks

Host CI created but no application CIs

The horizontal pattern succeeded but no vertical pattern fired. Root causes, in order of likelihood:

  1. Missing application credential: The OS credential worked, but the application-layer credential (SQL, Oracle, WAS, etc.) is missing or misconfigured. Vertical patterns silently skip without it.
  2. Application port not open: The stack-specific port (1433, 1521, 8880, etc.) is firewalled between MID and target.
  3. Application not running: Vertical patterns match running processes (sqlservr.exe, java with specific classpath, httpd, etc.). If stopped at scan time, no match.
  4. Pattern library outdated: Check sn_itom_pattern and sn_pattern_design for pending updates under System Applications > All Available Applications.

Service Mapping walk stops at the web tier

Service Mapping found the entry point but didn't traverse into backend tiers. Common causes:

  • Config files or connection strings pointing to the backend aren't readable with current credentials.
  • The backend is in a different network zone the MID Server can't reach — a second MID is needed.
  • The application uses external configuration (JNDI, Spring Cloud Config) that doesn't write backend addresses to local config files. May need a custom pattern or manual connection.

Oracle: listener found but no instance CI

The Listener and DB instance patterns are separate. If the listener is discovered but no instance CI appears, the Applicative credential is likely failing. Verify SELECT on the V$ views listed above, and that port 1521 is accessible for the Applicative credential's connection (not just the SSH read that found the listener process).

Everything works in dev but fails in production

The most common production-specific blockers:

  • DCOM dynamic port range restricted but the registry-based constraint was not applied on production targets.
  • WinRM was never enabled via Group Policy across production servers.
  • The service account was provisioned in a dev OU but not the production OU.
  • DNS resolution differs between dev and production MID Servers (split-horizon DNS, different search domains).
  • WinRM HTTPS certificate trust: Production often uses internal CA certs not in the MID Server's Java truststore. Import them into agent/jre/lib/security/cacerts using keytool -import, or configure an external TrustStore via wrapper-override.conf. Note: agent/keystore/agent_keystore.jks is for the MID's own identity cert (mTLS to instance), not for trusting remote server certificates.

Next Steps

  1. Distribute this guide to your network, security, and DBA teams with enough lead time for firewall change requests and service account provisioning.
  2. Gather your application entry points (URLs, hostnames, ports) for every application in scope.
  3. Work through the Tier 2 protocol baselines first. Once WMI/PowerShell (Windows) and SSH (Linux) work end-to-end from the MID Server, the Tier 3 additions are incremental.
  4. Validate with a single-IP Quick Discovery scan against one representative host per OS type.
  5. Run a Service Mapping scan against one entry point to confirm the topology walk traverses all layers.
  6. Review credential ordering and affinity rules to ensure the correct credential is tested first for each target range.

Appendix: Official Reference Sources

The following ServiceNow documentation pages, KB articles, and Community resources were used to synthesize this guide. URLs reference specific releases; for the latest, navigate to docs.servicenow.com and select your current release.

MID Server

Service Mapping and Discovery

Credentials and Permissions

Windows Discovery

Database Discovery

Additional Resources

Note: ServiceNow documentation URLs are release-specific. The links above reference the Vancouver, Utah, or Tokyo release bundles. When your instance is on a different release, navigate to docs.servicenow.com, select your release from the version picker, and search for the topic title.

Prepared for customer use  |  Not official ServiceNow documentation  |  Top-Down Discovery Readiness Guide v2.1  |  May 2026

0 Helpfuls
  • 51 Views
Version history
Last update:
an hour ago
Updated by:
ServiceNow Employee
Contributors