CAD Guide

MID Server and Discovery Fundamentals

Introduction

A recurring challenge for cloud-hosted platforms like ServiceNow is reaching resources inside corporate networks — servers behind firewalls, on-premise databases, internal monitoring systems. The MID Server solves this problem, and Discovery uses it to automatically populate your CMDB with CI data.

What Is a MID Server?

A MID Server (Management, Instrumentation, and Discovery) is a Java application installed on a server inside your network. It acts as a proxy:

ServiceNow Cloud Instance
        ↕  HTTPS (outbound from MID Server)
[Corporate Firewall]
        ↕
    MID Server
        ↕  Internal protocols (WMI, SSH, SNMP, JDBC)
    Network Devices / Servers / Databases

Key characteristics:

Installed inside your network — ServiceNow doesn't need inbound firewall rules
Communicates outbound only to your ServiceNow instance (HTTPS on port 443)
Runs as a Windows Service or Linux daemon
Multiple MID Servers can be deployed for redundancy or geographic coverage

MID Server Use Cases

Use Case	Description
Discovery	Scan network to populate CMDB CIs
Orchestration	Run scripts on remote servers
JDBC Integrations	Connect to on-premise databases
Agent-Based Monitoring	Collect metrics from internal systems
LDAP	Query internal Active Directory
Outbound REST	Proxy REST calls to internal APIs

Installing a MID Server

In ServiceNow: MID Server > Downloads → download the installer
On your server: Run the installer and configure:
- ServiceNow instance URL
- MID Server service account (username + password)
- MID Server name (unique identifier)
Start the MID Server service
In ServiceNow: MID Server > Servers → validate the new MID Server

Requirements:

Java 11+ (bundled with installer)
Network access to target IP ranges
Credentials for target systems (service accounts for Windows/Linux/SNMP)

Discovery Overview

Discovery is the process of scanning your network to find and classify CIs, then storing them in the CMDB.

Discovery Process

Discovery Schedule fires
    ↓
MID Server receives scan job
    ↓
Port scan of IP range (finds live hosts)
    ↓
Classification (what type of device is this?)
    ↓
Identification (do we already have this CI?)
    ↓
Population (create or update CI record)
    ↓
Relationship discovery (what does this connect to?)

Discovery Schedules

Discovery > Discovery Schedules > New

Field	Value
Name	Datacenter East — Weekly
MID Server	Select your MID Server
IP ranges	10.10.0.0/24, 10.10.1.0/24
Frequency	Weekly, Saturday 2:00 AM
Discover	IPs, Networks, Clouds

Multiple schedules can run with different frequencies — daily for critical infrastructure, weekly for the full estate.

Credentials

Discovery needs credentials to authenticate to target systems:

Discovery > Credentials > New

Credential Type	Use Case
Windows	WMI-based Windows server discovery
SSH	Linux/Unix server discovery
SNMP v1/v2/v3	Network device discovery
VMware	vSphere/ESXi discovery
AWS/Azure	Cloud resource discovery
JDBC	Database discovery

Credentials are stored encrypted. The MID Server retrieves them securely during scans.

Discovery Status and Troubleshooting

Discovery > Discovery Status

Every Discovery run creates a Status record showing:

IPs scanned
Hosts found
CIs created/updated
Errors and skipped hosts

Common Issues

Issue	Likely Cause	Fix
MID Server offline	Service stopped / network issue	Restart service; check firewall
Host not discovered	IP out of range / port blocked	Verify IP range; check port 135 (WMI) or 22 (SSH)
CI not updating	Identification rule mismatch	Review Identification Rules
Credential failure	Wrong password or locked account	Update credential record
Duplicate CIs	Multiple discovery sources	Configure reconciliation rules

CMDB Identification and Reconciliation

One of Discovery's most important features is preventing duplicate CIs. The Identification and Reconciliation Engine (IRE) evaluates:

Does a CI with this serial number/IP/name already exist?
If yes — update it (don't create a duplicate)
If no — create a new CI

Configure Identification Rules to match the right fields for each CI class:

CI Class: Windows Server
Identification Rule: Match by serial_number
  Fallback: Match by name + IP address

Best Practices

Deploy at least two MID Servers for redundancy in production
Use dedicated service accounts for MID Server authentication
Scope Discovery IP ranges to exclude production databases during business hours
Review Discovery Status after first run before enabling recurring schedules
Configure reconciliation rules before Discovery populates CIs at scale
Monitor MID Server queue depth — a backed-up queue indicates capacity issues
Rotate MID Server service account passwords and update the credential records

Conclusion

The MID Server is the bridge between ServiceNow's cloud infrastructure and your on-premise estate, and Discovery is the most scalable way to keep your CMDB accurate. Manual CI entry doesn't scale — Discovery does. Invest in proper MID Server redundancy, service account management, and identification rules, and your CMDB will maintain itself rather than becoming a data quality liability.