ServiceNow MID Server: Guides and Services

What MID Server Covers on the Now Platform

MID (Management, Instrumentation, Discovery) Server is a lightweight application that runs on your network (on-premise or in a private cloud) and acts as a bridge between the ServiceNow cloud instance and systems behind your firewall. It enables ServiceNow to discover on-premise infrastructure (servers, applications, databases), execute integrations with on-premise systems (sending API calls, retrieving data), and run probes that monitor on-premise resources. Without MID Server, ServiceNow (a cloud service) cannot reach inside your firewall to discover or integrate with on-premise systems.

The module answers operational questions: what infrastructure do we have? Which systems are on-premise vs. cloud? Can we integrate on-premise applications with ServiceNow? Do we have visibility into on-premise resource health and performance? How do we maintain security while enabling ServiceNow to access on-premise systems?

How MID Server Relates to Discovery and Integration

Discovery is the process of scanning networks and systems to identify infrastructure and build the CMDB. MID Server executes discovery probes on your network; the results are sent to ServiceNow where they are stored in the CMDB. Integration Hub and Orchestration use MID Server to execute outbound API calls to on-premise systems; the MID Server makes the call on your network, then returns the result to ServiceNow. MID Server is the operational enabler for both Discovery and Integration on on-premise infrastructure, sitting between ServiceNow cloud and your internal networks.

How to Use this Section

Start by assessing your infrastructure landscape. How much of your infrastructure is on-premise vs. cloud? Do you have multiple data centers or a single location? What systems and databases need to be discovered or integrated? These answers inform your MID Server deployment strategy: you may need one MID Server for a single site or multiple MID Servers distributed across data centers.

Implement MID Server in phases. Phase one: install MID Server on your network and verify connectivity to ServiceNow in a secure manner. Phase two: run discovery to identify on-premise infrastructure and build the CMDB with accurate data. Phase three: configure integrations so ServiceNow can communicate with on-premise systems. Phase four: monitor MID Server health and scale (add additional MID Servers) if load increases or if you need redundancy and failover protection.

Design for resilience. MID Server is a single point of failure; if it goes down, Discovery and integrations stop. Deploy multiple MID Servers in high-availability configurations, load-balanced across network segments, so that the failure of one MID Server doesn’t halt operations.

Typical Starting Problems

Organizations often have visibility into cloud infrastructure through native cloud integrations, but lack visibility into on-premise infrastructure. They cannot integrate legacy on-premise systems with ServiceNow without custom scripting or expensive third-party adapters. They have a single MID Server deployed without redundancy; when it fails, Discovery and integrations stop completely. MID Server guides help you plan and deploy MID Servers to enable end-to-end visibility and integration across hybrid infrastructure.

What Oblytech Provides

Oblytech helps design MID Server architecture aligned to your network topology and high-availability requirements, deploy and configure MID Servers with proper security controls, set up Discovery and integration workflows, troubleshoot connectivity and performance issues, and provide managed support for MID Server operations. We help monitor MID Server health and scale as your ServiceNow deployment grows and integration workload increases.

MID Server performance and monitoring are critical. Monitor MID Server logs for errors or performance degradation. Watch CPU and memory usage; if a MID Server is hitting limits, add capacity or distribute workload across additional MID Servers. Monitor network connectivity: if network latency is high between ServiceNow cloud and MID Server, discovery and integration performance will suffer.

Plan for MID Server updates and maintenance. MID Servers periodically need patching for security and bug fixes. In a high-availability configuration with multiple MID Servers, you can take one down for maintenance while others handle the load. Always test MID Server updates in a non-production environment first.

Matching your situation to the right MID Server guide

This section is a map rather than a manual. Readers arrive here with one of a handful of situations, and each situation calls for a different guide. A person who has never seen a MID Server needs a different starting point from an administrator whose discovery scans have started timing out. Reading the guides in the wrong order is a common way to lose time, because the early pages assume decisions that have not yet been made. The table below pairs each situation with the question it raises and the page that answers it first.

A reading order for a team that is starting from scratch

If nobody has operated a MID Server in your organization, work through the material in an order that puts decisions before configuration. The sequence below avoids the most common trap, which is reading installation detail before anyone has agreed where the server should live and who will own it.

1. Confirm which of your systems cannot be reached from the cloud instance directly, and which are reachable through a supported cloud integration instead. Only the first group needs a server inside your network.
2. Read the explainer on the MID Server’s role, so the team shares one definition of its role and its limits.
3. Agree an owner, an escalation route and a rule for who may request changes, using the governance guide before any server is built.
4. Use the implementation roadmap to sequence the work, and treat each phase as a checkpoint rather than a formality.
5. Only after those steps, read the troubleshooting guide, so the team knows what good operation looks like before it has to diagnose a failure.

How the subject areas connect

MID Server sits between two activities that are often planned separately. Discovery uses the server to reach hosts and collect configuration data, and integrations use it to call systems that the cloud instance cannot reach. Both depend on the same credentials, network paths and capacity, so a change made for one can quietly affect the other. A useful habit is to keep a single inventory of servers, the job types each one runs, and the credential sets they hold. Reviewing that inventory before adding a new job prevents the situation in which a routine scan starves an integration that was business-critical all along.

The conceptual definition of the component is set out in the concept entry for the MID Server, which is useful as a shared reference when the operations team and the integration team are using the same word to mean different things.

What this map does not cover

Each guide in this section answers one operational question in depth. They explain the reasoning behind a decision rather than click-by-click detail, which depends on your release and should be checked on your own instance before anyone runs it. If a technical step and a governance decision ever appear to conflict, the governance decision settles who approves the change.

Do we need a MID Server if every system we use is in the cloud?

Not necessarily. A MID Server is needed when the cloud instance must reach something only available inside your network, such as an on-premise directory, a database that is not exposed to the internet, or a host that discovery has to inspect directly. Many cloud platforms and SaaS applications connect through their own supported integration methods, which do not require a server inside your network. The first useful exercise is to list the systems that fall into the first group, because that list is often much shorter than the full estate.

Is one MID Server enough for a small estate?

It can be, provided the business accepts that a single server is also a single point of failure. The real question is how long discovery and integrations can stop before the impact is felt. Agree a limit with the service owner that you can justify in writing, and let that limit decide whether a second server is justified, rather than adopting a rule of thumb from another organization.

What should a team read if a MID Server already runs well?

Read the metrics and automation guides before changing anything. A server that runs without visible problems can still be drifting toward a capacity or patching problem, and the signals for that drift are easier to set up while the estate is calm. The governance guide is the other useful read, because a working server with an unclear owner is the situation most likely to break during the next staff change.

Talking through your MID Server estate

If you are not sure which situation in the table describes your team, the quickest way forward is a short conversation about what runs where and who depends on it.

Where to place a MID Server and what to check when it stops responding

A MID Server should sit as close as possible to the systems it has to reach, inside a network zone that can already talk to them. It only needs to connect outward to your ServiceNow instance. The server starts every conversation itself and collects its work from the instance’s ECC queue, so in most designs the firewall change is an outbound HTTPS rule for the MID Server host, not an inbound opening from the internet.

That one fact settles most placement questions. These rules cover the usual cases:

• Plan one server, or one cluster, for each network zone that discovery or integrations must cross. A MID Server cannot scan or call across a boundary its host cannot already cross.
• Where the workloads differ, keep discovery and integration traffic on separate servers, so a long scan does not hold up an urgent outbound call.
• Give every critical zone at least two servers grouped as a cluster, so one can be patched or can fail while the other keeps working.
• Size the host for the busiest job, not the average one. Discovery bursts normally use the most memory and processor time.

When a server shows as down or not validated, work through the causes in this order, because each one is cheaper to rule out than the next:

1. Confirm the MID Server service or daemon is running on the host, and that the host itself was not restarted or patched overnight.
2. Check the host can reach the instance outbound. A proxy change, a blocked certificate or traffic inspection on the path is a frequent cause after a network project.
3. Check the account the server signs in with: its password in the configuration file, and that the matching user still holds the role the server needs.
4. Look at the validation status. A newly installed server normally has to be validated by an administrator before it will take work.
5. Compare the server version with the instance. After an instance upgrade the server usually upgrades itself, and a blocked download leaves it behind.
6. Only then read the agent log and look for a backlog in the ECC queue.

Credentials for scans deserve their own owner. The guidance on governing discovery credentials explains how to scope them, and the Discovery guides show how the same server feeds the CMDB. If your servers also carry outbound calls from flows and spokes, read the Integration Hub guides before sizing the host.