ServiceNow MID Server Best Practices

A MID Server is the component that sits inside your network and carries jobs from the ServiceNow instance to the systems it manages, such as servers, databases and monitoring tools. Its design is judged by how it behaves under load and during an outage, so how many run and where they sit matters more than a clean install.

A MID Server design is judged by how it behaves under load, during a site outage and when a credential is rotated, not by whether it installed cleanly. The practices below cover sizing and capacity, geographic placement and redundancy, network connectivity and firewall rules, security configuration, monitoring, logging and version management, each with the reasoning behind it. The closing sections set out the design decisions that shape a MID Server before it is handed to operations, an operating checklist for that handover, and the signs that the design needs revisiting afterwards.

Practice 1: Sizing and Capacity Planning

MID Server performance depends on hardware, network, and job complexity. Start by estimating job volume: how many discovery jobs per day, how many integration jobs, how many script executions? A rough guideline: a single MID Server can handle 50-100 concurrent jobs. If you have higher volumes, use multiple MID Servers.

Hardware sizing: a MID Server typically needs 4-8 CPU cores, 8-16 GB RAM, and fast network connectivity to the ServiceNow instance. Monitor MID Server CPU and memory usage; if consistently high, you have a performance bottleneck. Reason: use dedicated hardware for MID Servers rather than running on shared infrastructure, so other workloads do not compete for resources.

Practice 2: Geographic Placement and Redundancy

Place MID Servers close to the systems they manage. If you have a data centre in the US and another in Europe, deploy MID Servers in both locations. This reduces latency and isolates failures: if the US MID Server is down, the Europe MID Server can still manage European systems.

Deploy at least two MID Servers for redundancy. When one fails, the other continues processing jobs. Jobs are spread across MID Servers only when they sit in a load-balancing cluster, and a fail-over cluster hands work to the next server in its set order. When you bring the failed MID Server back online, it re-enters the pool. This design ensures continuous connectivity even during maintenance or failures.

Practice 3: Network Connectivity and Firewalls

MID Servers must reach ServiceNow via HTTPS (encrypted communication). Confirm that your firewall allows outbound HTTPS (port 443) from the MID Server to the ServiceNow instance. Also confirm that MID Servers can reach the systems they manage: target servers (SSH, WMI), databases (JDBC), monitoring systems (APIs).

Use host-based firewalls on the MID Server itself to restrict which systems can connect to it. In principle, only your ServiceNow instance should send commands to MID Servers. In practice, MID Servers also need to reach target systems, so be precise about which outbound destinations are allowed.

Practice 4: Security Configuration

MID Servers store credentials for target systems: database passwords, server SSH keys, API tokens. Secure these credentials: store them in the ServiceNow platform (MID Server retrieves them when needed), not on the MID Server itself. Rotate credentials regularly. Limit which users can view or modify MID Server configuration.

Also apply principle of least privilege: a MID Server that manages only Windows servers does not need SSH keys to manage Unix servers. Create separate MID Servers for different system types or functions. This limits the impact if a MID Server is compromised.

Practice 5: Monitoring and Maintenance

Monitor MID Server health continuously: is it online, is it communicating with ServiceNow, what is its CPU and memory usage, are jobs succeeding or failing? ServiceNow provides monitoring dashboards. Set up alerts: if a MID Server is offline for longer than your alerting threshold, notify the team. If job success rate drops below a threshold, escalate.

Plan regular maintenance: OS patching, MID Server version updates, certificate renewal (MID Servers use SSL certificates to communicate with ServiceNow). Schedule maintenance during low-job-volume periods. Use your redundant MID Server: take one offline for maintenance while the other continues processing jobs.

Practice 6: Logging and Troubleshooting

MID Servers generate detailed logs of jobs executed, targets reached, and errors encountered. Enable detailed logging during troubleshooting, but disable it in production (it consumes disk space). If a job fails, check the MID Server logs: did it reach the target system, was authentication successful, did the target system respond as expected?

Common issues: network connectivity (firewall blocks MID Server), authentication (wrong credentials), target unavailability (system is down), or incompatible software (MID Server version does not support target system). The logs usually reveal which issue applies.

Practice 7: Version Management and Upgrades

MID Server versions should match or be close to your ServiceNow instance version. Older MID Servers may lack features or have bugs that are fixed in newer versions. Plan MID Server upgrades as part of your ServiceNow maintenance cycle. Test upgrades in a non-production environment first. During upgrade, jobs may queue briefly until the MID Server restarts; if you have redundant MID Servers, the impact is minimal.

The design decisions that shape a MID Server before it is handed to operations

Good practice for a MID Server is easier to follow when the design decisions behind it were made on purpose. Three choices shape almost everything that happens later: how many servers run, whether they share hosts with other workloads, and how close they sit to the systems they reach. Teams that leave these to whoever is installing the software often end up with a configuration that works on the day of handover and becomes awkward over time. The table sets out the choices and the consequences of each, so the design owner can see the trade-offs before the first installer runs.

None of these options is universally better. The right choice depends on how much the business would lose if collection stopped, and how many people can respond when it does. A single server with a sound failover plan can be the right answer for a modest estate, while a larger estate without grouping tends to become hard to change.

An operating checklist to complete before handover

Handover is the moment when a server moves from the project team to the people who will be paged for it. The checklist below is ordered so that each step depends on the one before it. Do not skip ahead to the monitoring step because it feels like the last thing to finish. Monitoring set up against a server that has no recorded owner tends to alert into a void.

1. Confirm the server appears in the platform records with the purpose, owner and failover answer recorded against it.
2. Run each job type the server will carry at least once in a supervised window, and capture the evidence of success for each.
3. Check the server’s connection behavior during a planned network interruption, and note how long it takes to recover and whether queued work resumes.
4. Confirm the logs are being kept where the operations team can read them, and that someone has tested reading them under the access they will really have.
5. Set the health signals the operations team will watch, and confirm each one reaches a person who can act on it.
6. Hold a short walk-through with the on-call group that covers the recovery steps for the two most likely failures.

Signs that the design needs revisiting after handover

A design is judged in operation. Certain patterns suggest the original choices no longer fit. Repeated scheduling clashes on one host point to a placement or sizing decision that was made before the job mix was known. A growing list of credentials attached to one server points to a credential model that needs grouping. A server that is hard to patch because nothing else can cover for it is a redundancy decision that was postponed rather than made. Each of these is cheaper to address by changing the design deliberately than by working around the symptom each week.

Is it better to start with one server and add more later?

That path is common and often sensible, provided the first server is installed in a way that can be extended. Name it for its function and not its only current job, record which jobs depend on it, and avoid tying every credential to it personally. Adding a second server later is then a matter of moving some jobs, not rebuilding the estate.

Should a MID Server run on a host shared with other applications?

It can, when the owners of both workloads agree the resource use and the timing of heavy work. Problems arise when the sharing was never agreed, because a slowdown in the other application appears as a MID Server fault. Write the agreement down, and include the other application’s owner in the first review of capacity.

How do we know the design choices are still right a year later?

Review them against the things that have changed: the number of job types, the number of systems reached, the number of people on the rota and the business services that now depend on collection. A design that matched the estate when it was built may no longer match it, and the review is the time to find out.

Getting the design reviewed before handover

Design choices for a MID Server are easier to get right when someone who has made them before reviews the plan. The implementation roadmap is the page for sequencing these choices, and the integration patterns guide is the page for job-type load across integrations.