question Re: MID server shows version mismatch in ITOM forum

MID server shows version mismatch

RavishShett — Thu, 25 Jun 2026 20:24:51 GMT

Hi all,

We installed MID servers recently and it seems there is version mismatch between the MID server version and the instance version. Probably because we used MID server installer files from another ServiceNow instance. I opened these MID server records in the ecc_agent table and clicked on the 'Upgrade MID' related link, but nothing happens after the status briefly showing 'Upgrading'. I tried it a few times. What can we do here?

Thanks,

Ravish

Re: MID server shows version mismatch

SGienow — Thu, 25 Jun 2026 20:50:24 GMT

A lot of this may depend on your OS, the permissions you setup, and the way you setup an account.

If its windows, then the folder for the mid server needs to have the service account to have Full Control over it as well as have the ability to start and stop the service, and log on as a service.

Look in the mid server logs for why it won't upgrade.
See below:
https://www.servicenow.com/docs/r/servicenow-platform/mid-server/mid-server-installation.html

Re: MID server shows version mismatch

shubham007 — Thu, 25 Jun 2026 21:41:59 GMT

Why This Happens

This usually occurs when the MID Server is installed using files from a different ServiceNow instance, causing the MID Server version to differ from the instance version.

The good news is that MID Servers are designed to detect and correct version mismatches automatically.

How Auto-Upgrade Works

The MID Server checks its version in three ways:

Trigger What it does

Hourly Auto-Upgrade	Checks the instance version every hour and upgrades if required.
On Startup	Performs a version check whenever the MID Server service starts.
Manual Upgrade	Clicking Upgrade on the MID Server record starts the upgrade immediately.

In most cases, the issue resolves within an hour. If it doesn't, something is preventing the upgrade.

Why the Upgrade Fails

Before upgrading, the MID Server performs several validation checks. If any of them fail, the upgrade stops.

1. Download Access (Check First)

The MID Server must be able to reach install.service-now.com to download the required files.

Allow outbound TCP port 443 to install.service-now.com through the firewall.

2. Disk Space

Ensure the MID Server host has at least 1 GB of free disk space.

3. Service Account Permissions

The MID Server service account must have write access to the temporary directory:

Windows: C:\WINNT\TEMP
Linux: /tmp

4. Antivirus

Security tools (such as Cisco AMP) may lock files during the upgrade. Configure antivirus exclusions for the MID Server installation directory if needed.

How to Troubleshoot

Step 1 – Review the Logs

After clicking Upgrade, check these logs:

agent/logs/agent0.log.0 – Primary upgrade log
agent/logs/wrapper.log – JVM/service events
C:\WINNT\TEMP\glide-dist-upgrade.log – Created when the upgrade fails critically

You can also collect logs from the instance:

Open the MID Server record.
Click Grab MID logs, files and thread dump.
Go to ECC Queue, filter Source = grabLog, and download the attached payload.txt files.

Step 2 – Check MID Server Issues

Review the MID Server Issues related list on the MID Server record. Any detected problems are also stored in the ecc_agent_issue table.

Step 3 – Verify Connectivity

Confirm the MID Server can reach the download server:

telnet install.service-now.com 443

Or in PowerShell:

Test-NetConnection -ComputerName install.service-now.com -Port 443

Step 4 – Retry the Upgrade

After fixing any issues:

Restart the MID Server service.
Trigger a manual Upgrade, or wait for the next hourly auto-upgrade.

Watch Out for Downgrades

If the installed MID Server version is newer than the instance version, a standard upgrade won't downgrade it.

Downgrades are supported only within the same release family.
For major release differences, uninstall the MID Server and reinstall it using the installation files downloaded from the correct ServiceNow instance.

Re: MID server shows version mismatch

Tanushree Maiti — Fri, 26 Jun 2026 05:17:16 GMT

Hi @RavishShett

1) Refer KB: KB0958502 MID Server version compatibility

Resolution

The next step in this situation is to figure out why it didn't upgrade, and fix that so that the MID Server can upgrade itself. There are many possible reasons.

If the MID Server remains 'Up', the agent0.log.0 log file is most useful, as it is likely to be Pre-checks failing, so find the most recent lines including "AutoUpgrade". Or it could be still Up because the upgrade was rolled-back, in which case wrapper.log will explain why.

If it is 'Down' since the instance upgrade ended, then wrapper.log is most useful, as the recent logs from the temporary and separate upgrade process, that does the deletes and file changes, will be in there. That will confirm if the MID Server service could not be started again, and why.

If the MID Server is Pinned, then un-pin it. There are no valid reasons, apart from during testing, or as an emergency workaround, to need to pin a MID Server to the 'wrong' version. Delete any mid.pinned.version and mid.version.override MID Server Properties or MID Server Configuration Parameters.

2) https://www.servicenow.com/community/developer-forum/mid-server-invalid-version/m-p/2125056

3) Refer: KB0786475 MID Servers and Clones

If post that issue is not resolved , raise a case (Hi Ticket) with your ServiceNow Vendor , if it is not PDI.

Re: MID server shows version mismatch

Vinayak2443 — Fri, 26 Jun 2026 06:16:44 GMT

Using installers from another instance is a common cause of version mismatches. Since the version mismatch stems from using the wrong installer, the most reliable fix is a manual reinstall rather than relying on the auto-upgrade button. Download the correct MID server installer directly from your instance.

Please refer the KB from the link below.
MID Server version compatibility - Support and Troubleshooting

Re: MID server shows version mismatch

pr8172510 — Fri, 26 Jun 2026 06:48:19 GMT

Hi @RavishShett,

A version mismatch is expected if the MID Server was installed using binaries from a different instance. Normally, the MID Server should automatically upgrade to match the instance version.

Since the Upgrade MID action is not completing
check

agent0.log.0 for AutoUpgrade messages and pre-check failures.
wrapper.log for upgrade or service restart errors.
Ensure the MID Server is not pinned (mid.pinned.version or mid.version.override).
Verify the MID Server can reach install.service-now.com over HTTPS (port 443).
Confirm the MID Server service account has permission to update the MID Server installation directory.

If the auto-upgrade continues to fail after resolving any pre-check or connectivity issues, reinstall the MID Server using the installer downloaded from the target ServiceNow instance.

Re: MID server shows version mismatch

Vinayak2443 — Fri, 26 Jun 2026 08:38:27 GMT

Please refer the KB from the link below.
MID Server version compatibility - Support and Troubleshooting

Re: MID server shows version mismatch

Vinayak2443 — Fri, 26 Jun 2026 08:45:30 GMT

Since the version mismatch stems from using the wrong installer, the most reliable fix is a manual reinstall rather than relying on the auto-upgrade button. Download the correct MID server installer directly from your instance