MID Server Deep Dive — Architecture, Configuration & Operations
You were introduced to the MID Server concept in Part 2 (SGC). Now that you understand how Discovery works, this topic goes deep: installation, the ECC Queue protocol, worker threads, cluster configuration, performance tuning, and every troubleshooting scenario the exam tests. The MID Server is the backbone of all on-premise integrations — mastering it is essential.
MID Server Architecture — What It Is and How It Works
The Management, Instrumentation, and Discovery (MID) Server is a Java application that runs on a server inside your network. Its job is to act as a secure, bidirectional proxy between your ServiceNow cloud instance and resources that live inside firewalled private networks.
The critical insight — repeated from Part 2 because it's exam-tested so frequently — is that the MID Server makes outbound connections only. It reaches out to ServiceNow; ServiceNow does not reach in to the MID Server. This means:
- No inbound firewall holes required
- Only outbound HTTPS (port 443) to your ServiceNow instance must be allowed
- The MID Server maintains a persistent polling connection to the ECC Queue
The Three Layers of MID Server Communication
ecc_queue table. Receives results the same way. Never initiates an outbound connection to the MID Server directly.MID Server Installation and Initial Setup
Understanding the installation process helps you answer "what is required for a MID Server to start working?" questions on the exam.
Prerequisites
- Java 11 or later — MID Server is a Java application. Java must be installed on the host server.
- 64-bit OS — Windows Server 2012 R2+ or RHEL/CentOS/Ubuntu Linux (64-bit)
- RAM: Minimum 2 GB dedicated to the MID Server process; 4–8 GB recommended for high-load environments
- Network: Outbound HTTPS (port 443) to
your-instance.service-now.commust not be blocked - Service account: A dedicated Windows or Linux user account (not a personal account) to run the MID Server process
Installation Steps (Conceptual)
- Download the installer from your ServiceNow instance: Navigate to MID Server → Downloads and download the Windows installer or Linux package.
- Run the installer on your host server. It installs the MID Server files and creates the base directory structure.
-
Configure
config.xml— This file inside the MID Server installation directory contains the connection settings:url— Your ServiceNow instance URLmid.instance.username— ServiceNow service account usernamemid.instance.password— ServiceNow service account password (stored encrypted)name— The MID Server name (must match what you register in ServiceNow)
- Start the MID Server as a Windows service or Linux daemon.
- Register and Validate in ServiceNow. The MID Server appears under MID Server → Servers as "Pending Validation." An admin must validate it.
config.xml on the
MID Server host. This is separate from the target device credentials (SSH keys,
SNMP community strings) which are stored in ServiceNow's Credential Vault.
Many candidates confuse these two types of credentials.
The MID Server Service Account in ServiceNow
The ServiceNow user account that the MID Server uses must have the mid_server role in ServiceNow. This role grants:
- Access to read from and write to the ECC Queue
- Access to read Credential records (so it can retrieve target device credentials)
- Access to create and update CMDB records (via IRE, not direct writes)
- Access to Discovery schedule and behavior configurations
Best practice: use a dedicated service account with only the mid_server role. Do not give it admin access.
MID Server Validation — The Gate Before It Can Work
After a MID Server starts and connects to ServiceNow, it enters a Pending Validation state. It cannot process any work until a ServiceNow administrator validates it. This is a deliberate security control — it prevents unauthorized MID Servers from being used to scan your network.
Validation Process
- Navigate to MID Server → Servers
- Find the new MID Server in the list (state = "Pending Validation")
- Open the record and verify: server name, IP, OS version, Java version, MID Server version
- Click Validate
- ServiceNow sends a validation challenge to the MID Server, which must respond correctly
- State changes to "Up" — the MID Server is now active and can receive work
Validation States
| State | Meaning | Action Required |
|---|---|---|
| Pending Validation | MID Server connected but not yet approved | Admin must validate |
| Up | Validated and actively polling ECC Queue | None — fully operational |
| Down | MID Server process stopped or lost connectivity | Check MID Server process; check network connectivity |
| Skipped | MID Server intentionally excluded from receiving work | Admin set skipped — intentional |
| Upgraded | MID Server was upgraded; requires re-validation | Admin must re-validate after upgrade |
The ECC Queue — ServiceNow's Message Bus to MID Servers
The External Communication Channel (ECC) Queue is a table in ServiceNow (ecc_queue) that acts as the message bus between ServiceNow and all MID Servers. Understanding the ECC Queue is critical for debugging Discovery issues.
ECC Queue Input vs. Output
| Queue Side | Direction | Contains | Who Writes It |
|---|---|---|---|
| Input Queue | ServiceNow → MID Server | Instructions: "Scan this IP," "Run this probe," "Fetch this API" | ServiceNow (Discovery schedule, SGC scheduler) |
| Output Queue | MID Server → ServiceNow | Results: raw probe data, connection logs, error messages | MID Server (after executing instructions) |
ECC Queue Record Fields
- Agent: Which MID Server this message targets or came from
- Topic: The type of instruction (e.g., "DiscoveryProbe", "REST")
- Name: Specific operation name
- Payload: XML or JSON payload containing the actual data or result
- State: ready/processing/processed/error
- Error string: If state is error, what went wrong
Monitoring the ECC Queue for Errors
When Discovery or SGC seems stuck or not producing results, check the ECC Queue: navigate to MID Server → ECC Queue. Look for:
- Messages in "error" state — read the error_string field
- Messages stuck in "ready" state for a long time — MID Server may be down
- Messages stuck in "processing" — a probe is taking too long; may be a timeout issue
Worker Threads — MID Server Concurrency
A MID Server doesn't process one Discovery job at a time. It has a pool of worker threads that allow it to handle multiple probe executions simultaneously. This is how a single MID Server can scan thousands of IP addresses efficiently.
How Worker Threads Work
When the MID Server polls the ECC Queue and finds work items:
- It picks up multiple items from the Input Queue at once (configurable batch size)
- Each work item is assigned to an available worker thread
- Worker threads execute probes in parallel
- Results are posted to the Output Queue as each thread completes
- Threads return to the pool and pick up more work
Configuring Worker Thread Count
The thread count is configured in the MID Server's system properties (not config.xml; these are set in ServiceNow under MID Server → Properties for that specific MID Server):
- mid.discovery.script.max_count — Maximum concurrent Discovery probes
- mid.perfmon.max_count — Maximum concurrent performance monitoring probes
- Default is typically 100 threads; can be increased for high-volume environments
Throttling and Rate Limiting
ServiceNow provides throttling mechanisms to prevent Discovery from overwhelming your network or target devices:
- Max simultaneous probes per MID Server: Limits how many concurrent connections the MID Server makes to target devices
- Discovery timing policies: Slow down scans during business hours
- Per-IP rate limiting: Limit how quickly probes run against any single target
IP Range Assignment and Application Routing
Two key configurations control which MID Server handles which work: IP Range Assignment (for Discovery) and Application Assignment (for all work types).
IP Range Assignment
Every MID Server record has a related list of IP Ranges. When a Discovery Schedule fires for an IP range, ServiceNow looks at which MID Server "owns" that range and routes the job there.
Example:
- MID-US-East owns ranges 10.0.0.0/16 and 172.16.0.0/24
- MID-US-West owns ranges 192.168.0.0/16 and 10.100.0.0/16
When a Discovery Schedule runs against 10.0.5.0/24, ServiceNow routes it to MID-US-East automatically. If no MID Server owns a particular IP range, Discovery will fail for that range.
Application Assignment
Each MID Server can be assigned one or more Applications — the types of work it handles:
| Application | What It Enables | Typical Use |
|---|---|---|
| Discovery | Run Discovery probes and patterns against network devices | All on-premise infrastructure scanning |
| Service Graph Connector | Proxy API calls from SGC to on-premise data sources | VMware vCenter, on-premise monitoring tools |
| Orchestration | Execute workflow activities on remote systems (install software, run scripts) | IT automation flows |
| Event Management | Receive inbound alerts from monitoring tools (SNMP traps, REST alerts) | AIOps / Event Management integration |
| IntegrationHub | Execute spoke actions against on-premise systems | Flow Designer integrations with internal systems |
A single MID Server can have all applications enabled, or you can specialize MID Servers (one for Discovery only, one for SGC only) for performance isolation.
MID Server Clusters — High Availability and Load Distribution
A single MID Server is a single point of failure for all on-premise Discovery and integrations. If it goes down, Discovery stops, SGC stops, orchestration stops. MID Server Clusters solve this by grouping multiple MID Servers so they can share and distribute work.
How Cluster Work Distribution Works
- Cluster members share a common IP range assignment pool
- ServiceNow distributes work items across available cluster members in round-robin or load-based fashion
- If one member goes down, the others pick up its queued work
- New cluster members can be added dynamically without disrupting ongoing work
Primary and Secondary MID Servers
Within a cluster, you can designate a Primary and one or more Secondary MID Servers. For work types that require consistency (like certain SGC connections that maintain session state), ServiceNow prefers the Primary. If the Primary is down, a Secondary takes over.
Cluster vs. Individual MID Server — When to Use Each
| Scenario | Recommendation |
|---|---|
| Small environment (< 500 CIs) | Single MID Server is sufficient |
| Production environment requiring 99%+ uptime | Minimum 2-node cluster (Primary + Secondary) |
| Large environment with many IP ranges and CI classes | Multiple MID Servers per network segment; cluster within segment |
| Geographically distributed infrastructure | One MID Server per site; IP ranges assigned by site |
MID Server Auto-Upgrade and Version Management
ServiceNow instances are upgraded regularly (twice a year for major releases, plus patches). The MID Server version must stay compatible with the ServiceNow instance version. Auto-upgrade handles this automatically.
How Auto-Upgrade Works
- After a ServiceNow instance upgrade, it checks the version of each connected MID Server
- If the MID Server version is outdated, ServiceNow pushes the new MID Server installer to the host via the ECC Queue
- The MID Server process installs the upgrade and restarts
- After restart, the MID Server must be re-validated before it resumes work
Controlling Auto-Upgrade
- Auto-upgrade enabled (default): MID Server upgrades automatically when the instance upgrades
- Auto-upgrade disabled: Admin must manually upgrade each MID Server. Risky — an incompatible version may cause errors or disconnection
- Upgrade window: You can configure when auto-upgrade is allowed to run (e.g., only during maintenance windows)
MID Server Troubleshooting — Common Failure Patterns
MID Server Shows "Down" in ServiceNow
ServiceNow marks a MID Server as "Down" when it stops receiving heartbeat messages from the MID Server process.
- Check if the MID Server process/service is running on the host (Task Manager on Windows,
systemctl status mid-serveron Linux) - Check network: can the host reach
your-instance.service-now.com:443? - Check for proxy changes: many MID Servers run behind a corporate proxy — if the proxy changed, update
config.xml - Check MID Server logs at
INSTALL_DIR/logs/agent0.log.0for Java stack traces or connection errors
MID Server Is Up but Discovery Produces No Results
- Check IP range assignment: does the MID Server own the IP range in the Discovery Schedule?
- Check Application assignment: is "Discovery" enabled for this MID Server?
- Check ECC Queue for stuck messages
- Check Discovery Behavior: are the correct probes included?
- Check if firewall rules on the MID Server host allow it to reach the target IP range
MID Server Memory / Performance Issues
- Java heap OOM: MID Server ran out of memory. Increase heap size in
wrapper.conf: setwrapper.java.maxmemory=2048(in MB) - High CPU: Too many concurrent worker threads. Reduce thread count or add another MID Server
- Slow probe results: Target devices are slow to respond. Increase probe timeout in Discovery behavior settings
MID Server Logs
Key log files in the MID Server installation directory:
logs/agent0.log.0— Main MID Server process log. Shows startup, connectivity, probe executionlogs/boot.log— Startup and JVM initializationlogs/mid-upgrade.log— Auto-upgrade events
MID Server — Key Facts
- MID Server = Java app installed on-premise. Makes outbound HTTPS to ServiceNow only. No inbound ports needed.
- ECC Queue = message bus. Input = instructions from ServiceNow to MID. Output = results from MID to ServiceNow.
- config.xml = connection config file on MID Server host. Contains ServiceNow URL and service account credentials.
- Service account needs
mid_serverrole in ServiceNow. Not admin. - Validation required before any work can be processed. State: Pending → Up.
- Re-validation required after upgrade. MID Server goes to "Upgraded" state — admin must re-validate.
- IP Range assignment routes Discovery work to the correct MID Server.
- Application assignment controls which types of work (Discovery, SGC, Orchestration) the MID Server handles.
- Clusters provide HA. Members share IP ranges and distribute work. Cluster members must be in same network segment for Discovery.
- Worker threads = concurrency. Too many → OOM. Too few → slow. Default 100 threads.
- MID Server logs are in
INSTALL_DIR/logs/agent0.log.0.
Term Grid
Practice Questions
Click any question to reveal the answer and explanation.
Practice Questions
4 questions · Select an answer to see the explanation immediately.
How does a MID Server communicate with the ServiceNow instance?
B is correct. The MID Server is a Java application deployed inside the corporate network that makes outbound HTTPS connections to ServiceNow. No inbound firewall holes to the MID Server host are required. This design allows it to operate behind strict enterprise firewalls. A describes inbound connections which is the opposite of how MID Server works. C and D are incorrect.