[object Object]

The MID server worked great in the proof of concept and started timing out two months into production rollout when Discovery scope expanded. The architecture team had specced a single MID server for “the data center,” nobody monitored ECC queue depth, and the credential rotation last month broke three integrations the MID was running. MID server architecture is consistently under-invested in until it bites.

What a MID Server Does

A MID server is a lightweight on-premises agent that lets the instance reach behind-firewall resources for Discovery, Orchestration, IntegrationHub spokes that run on-prem, and the platform’s interaction with internal endpoints generally. It polls the instance for work via outbound HTTPS — no inbound firewall holes needed. The polling model is the right architectural choice for security but means latency on the work depends on the polling interval and the queue depth.

MID server in the architecture:
  ServiceNow instance (cloud)
    |  outbound HTTPS poll
  MID server (on-prem)
    |  protocol-specific (SSH, WMI, SNMP, JDBC, REST)
  Internal targets (CIs, APIs, databases)

Sizing Isn’t Guesswork

MID server sizing depends on workload — number of probes per hour, script execution load, integration call volume, parallelism requirements. Use the MID server capacity calculator and validate against measured load in production. Most organizations under-provision because the proof-of-concept workload was a fraction of production. Plan for double the initial sizing and monitor utilization (CPU, memory, ECC queue depth) continuously.

Load Balance via Clusters

Do not run a single MID server in production. Run two or more in a cluster so probes distribute and any single failure is survivable. Dedicated clusters per use case (Discovery cluster, Integration cluster, Orchestration cluster) keep noisy neighbors out — a Discovery scan storm should not block urgent integration calls. Cluster membership is configured on the MID server records; the platform handles work distribution within a cluster automatically.

Cluster architecture pattern:
  cluster_discovery_us_east (3 MID servers)
  cluster_integration_us_east (2 MID servers)
  cluster_discovery_eu_west (3 MID servers)
  cluster_integration_eu_west (2 MID servers)
  Each cluster monitored separately, load-balanced internally

Credentials and the Credential Vault

Credentials live in the MID server’s local credential cache or in the platform’s external credential store integration (CyberArk, HashiCorp Vault, etc.). Never put production credentials in plaintext scripts. The discovery credential store handles rotation when you invest the setup time — without it, every credential change is a coordinated outage.

// Reference credentials by ID, never inline
var probeCfg = {
  cred_id: 'cred_oracle_prod',
  target: ciHostname,
  query: 'SELECT * FROM v$instance'
};

Upgrade Cadence

MID servers auto-upgrade with the instance by default. In regulated environments or where the MID server runs alongside complex on-prem dependencies, pin the version and test upgrades in sub-prod first. MID server incompatibility with the instance version breaks Discovery silently — probes succeed but sensors fail to parse. Test the full Discovery cycle in sub-prod after every MID upgrade, not just the connection.

Common Failure Modes

Single MID server with no failover — the host reboots for OS patching and the instance loses on-prem reach for the duration. Cluster membership configured but probes pinned to a single MID by accident — defeats the cluster’s purpose. ECC queue not monitored — the queue fills, processing falls behind, alerts come from downstream consumers instead of the queue itself. Credentials pinned to specific MID servers rather than the cluster — adding a new MID requires re-provisioning every credential.

What Changed in 2026

Newer releases improved MID server topology visualization and the cluster health dashboards. The Machine Identity Console (Zurich) inventories MID server credentials alongside other non-human identities, which simplifies the rotation story. Older instances still benefit from manual credential audits.

Cost Considerations

MID server hosts are typically modest VMs (4-8 vCPU, 8-16 GB RAM) but production sizing should validate against measured load. Multiple smaller MID servers in a cluster usually outperform a single large one because of probe-level parallelism. Network egress from the on-prem cluster to the cloud instance can be meaningful at scale; account for it in network capacity planning.

Implementation Sequence

Start with a two-MID cluster per region, monitor for two weeks under realistic load, scale up before scope expansion. Establish credential rotation procedures before adding integrations that need credentials. Pin the MID version policy explicitly (auto-upgrade or controlled upgrade) and test in sub-prod for any controlled-upgrade environment. The “we will scale when we need to” approach is how production hits the MID capacity wall during a Discovery scope expansion.

What to do this week: open the MID server health dashboard and check ECC queue depth and host utilization for each MID; anything consistently above 70% utilization is a capacity warning before it becomes an incident.

[object Object]
Share