ServiceNow MID Server Requirements Workshop Questions

This page is a set of workshop questions for planning MID Server placement before Discovery, monitoring or orchestration goes live. It helps you decide where each MID Server runs, which network paths and credentials it needs, how resilient it must be, who supports it, and which open answers should stop the go-live.

Infrastructure and Network Questions

These questions establish where MID Servers will run and how they will communicate with ServiceNow and your infrastructure.

Where will the MID Servers run? On-premises servers, cloud VMs, or a mix? Physical or virtual? This determines network topology and access requirements. On-premises MID Servers need network access to on-premises systems. Cloud MID Servers need access to cloud systems. Most organizations use a mix.

What network connectivity exists between MID Servers and your monitored systems? Do MID Servers need VPN access? Direct network access? Firewall rules? Document the existing network topology so you can plan MID Server placement. If a system is firewalled and only accessible from inside the firewall, you need a MID Server inside the firewall to monitor it.

What bandwidth will MID Servers use? Continuous monitoring generates data. If MID Servers are on slow network links, you might have performance issues. Test with realistic data volumes before production.

Capacity and High Availability Questions

These questions determine how many MID Servers you need and how resilient they must be.

How many systems will each MID Server monitor? One MID Server can monitor dozens of systems. More systems per MID Server means lower total cost but single point of failure. Fewer systems per server means higher cost but better resilience. Define acceptable risk.

What happens if a MID Server fails? Do monitored systems go dark until the MID Server recovers? Do you have another MID Server that can take over? For mission-critical monitoring, having multiple MID Servers provides resilience. For non-critical monitoring, one MID Server might be sufficient.

What is your disaster recovery requirement? If a data center fails, do you need to recover MID Server monitoring? If yes, you need MID Servers in multiple data centers or ability to quickly stand up a new MID Server. For mission-critical applications, having MID Servers in geographically separate locations ensures monitoring continuity.

Security and Access Control Questions

These questions establish what permissions MID Servers need and how to limit their access.

What systems will MID Servers connect to? Databases, APIs, cloud providers, monitoring tools? Each system has different credential and permission requirements. MID Servers running as one identity can only access systems that identity has access to. If you need to monitor systems with different credentials, you might need multiple MID Servers.

How will MID Servers authenticate to monitored systems? With stored credentials, certificates, or API keys? Stored credentials need to be securely managed and rotated. API keys need to be issued and revoked. Define credential management procedures.

What data will MID Servers access? If MID Servers access sensitive systems, they need security reviews and audit capability. If they access customer data or financial systems, compliance teams need to review.

Integration Questions

These questions determine what ServiceNow modules MID Servers need to connect to and what data flows.

What ServiceNow modules will use MID Servers? Discovery, monitoring, CMDB population, orchestration, cloud provisioning? Different modules have different MID Server requirements. Discovery generates high data volume. Orchestration needs reliable execution. Define which modules MID Servers support.

What third-party integrations will MID Servers facilitate? Integrations to monitoring tools, cloud providers, ITSM tools, databases? Each integration has different credential and network requirements.

Operational Readiness Questions

These questions establish what support is needed to operate MID Servers successfully.

Who will install, configure, and maintain MID Servers? Do you have in-house expertise, or do you need vendor support? Training or hiring might be needed. MID Server administration requires understanding network configuration, security, and ServiceNow integration patterns.

How will you monitor MID Server health? Are you monitoring whether MID Servers are running, responding, and successfully collecting data? If MID Server health monitoring is missing, failures will be undetected. Set up alerts for MID Server status, recent probe execution, and data collection latency.

What is your support escalation plan? When a MID Server fails, who do you contact? What is the expected recovery time? Document these procedures before deployment.

Warning Signs

If stakeholders cannot agree on how many systems each MID Server should monitor, that disagreement reflects different risk tolerances that need to be addressed explicitly, not glossed over. If security review raises concerns about MID Server access, address those before deployment. If network infrastructure does not support MID Server traffic, you will have performance problems.

Turning workshop answers into a placement decision

A workshop produces a list of answers. A placement decision needs something more specific: a count of MID Server clusters, the network zone each cluster sits in, the identity each cluster uses to reach targets, and the owner who gets paged when that cluster stops. The space between those two is where designs usually fail. Teams leave the room with a tidy transcript and then discover that two answers contradict each other, such as “all discovery runs nightly” alongside “the database team scans only during its change window”. Before anyone draws a diagram, read the answers back and sort each one into a placement input, a capacity input, or a constraint that can block go-live.

Many of the answers you collect will be placement inputs. They tell you which network zone a server must sit in and which targets it must reach. Capacity inputs are harder because the honest answer is often a guess. Treat a guessed capacity figure as a hypothesis to test in staging, not as a number to put in a design document. Constraints are the answers that say “no” in some form: the security team will not accept a shared identity, the change board will not approve inbound rules, or the data center cannot host a second virtual machine until a later quarter. Discovery-heavy estates raise the same questions in a sharper form, which is why the discovery requirements questions are worth reading alongside these. A constraint should never be averaged out against a benefit. It either fits the design or the design changes.

Decision table for common workshop answers

The table below shows how a few typical answers translate into design choices. It is a reading aid, not a formula. The right column is where the workshop should record its follow-up, because a design built on an unverified answer is a common reason a MID Server has to be rebuilt later.

How to run the follow-up after the workshop

Workshops often fail when the output is filed and nobody owns the open items. The sequence below keeps the answers testable and moves each one to a named person. Run it in the order shown, because later steps depend on the inventory built in the early ones.

1. Build a placement inventory with one row per target system, its network zone, its credential owner and the ServiceNow module that uses it.
2. Mark every answer as a placement input, a capacity input or a constraint, and record the person who gave it.
3. For each capacity input, write the test that would prove or disprove it, such as a timed scan of one representative subnet.
4. For each constraint, record who can waive it. If nobody can, the constraint is a design boundary, not an open item.
5. Schedule a second session with the network and identity owners only. Ask them to confirm or reject the inventory rows, not to re-answer the whole list.
6. Freeze the inventory and attach it to the design record. Any later change to a target goes through the same review.

Answers that should stop a go-live

Some answers are not reasons to slow down; they are reasons to stop. An unresolved identity model for a privileged target is one. So is a plan that depends on a firewall change nobody has requested. A third is a monitoring requirement that no one can name an owner for, because the server will run without anyone watching it. Where the identity question is the one holding things up, the access design for MID Servers covers the access questions a security reviewer is likely to ask next. When you see one of these, record it as a blocker with an owner and a date for re-review, and do not let the design proceed around it.

The hardest case is a stakeholder who wants every target covered and every risk accepted at once. Ask them to rank the targets by what happens if they go dark for a working day. That ranking usually shows which targets justify a second cluster and which can wait for a later phase.

Which answers from the workshop are safe to reuse for a second estate

Answers about process are usually reusable: how changes are approved, how certificates are renewed, and who receives alerts. Answers about topology are rarely reusable, because a second estate has different zones and different owners. Copy the process answers across and re-ask every topology question.

Why the workshop should not decide the cluster count alone

The number of clusters follows from zones, identities and recovery expectations, and the plain-language overview of how a MID Server sits between cloud and local systems is a useful check that everyone in the room means the same thing by a cluster. A workshop can surface those inputs, but the count should come out of the placement inventory. Settling it in the room tends to produce a number that looks tidy and fails the first time a zone needs its own host.

What to do when the people who answered are no longer on the project

Record the answer with the source role, not only the name, and flag any answer older than the current network design. Re-confirm those rows with whoever now holds the role before the placement inventory is frozen.

Whether a workshop is needed when the estate is small

A small estate with one zone and one identity can skip the full question set. The inventory and the blocker list still need to exist, because they are what a later audit or incident review will ask for.

Going through the inventory with a second reviewer usually separates the open items that block the design from those that are simply unfinished paperwork.