Upgrade MID Servers manually, or automatically through their host computers. The instance
automatically tests to identify issues before MID Servers upgrade. Pin MID Servers
to specific versions using system properties.
The MID Server cannot auto-upgrade on a Windows host if the Windows
Application Experience service is disabled. For information on the error that is displayed
and instructions for re-enabling this service, see KB0597552
Access to the MID Server download site
The MID Server host computer
must have access to the ServiceNow download site at
install.service-now.com to upgrade automatically. If you have a
self-hosted ServiceNow environment that blocks access to the download site, you must
import the MID Server installer package into your MID Server hosts manually. For
instructions, see KB0760123 in the Self-Hosted knowledge base.
- Automatic: Allow the instance to automatically upgrade the MID
Server. This functionality is available by default. Automatic upgrade occurs:
- Every hour, when the MID Server checks with the instance to see if there is a
different version available for upgrade. You cannot modify this time period.
- When the instance is upgraded and the MID Server for that version is different
than the version currently on the MID Server.
- When the MID Server pre-upgrade test passes without an error. Any errors encountered during
this automatic test prevent the upgrade from occurring until the issues are
resolved. The pre-upgrade test is enabled by default, but can be disabled by adding
and setting a system property.
- Manual: Manually start the upgrade by clicking a related link
on the MID Server record. Use this method when you do not want to wait until the next
hourly automatic update or if your upgrade failed and you want to force an upgrade. See
Upgrade the MID Server manually for instructions.
The Upgrade state
The instance initiates the upgrade by sending the autoUpgrade system
command to the MID Server. Starting with MID Servers upgrading from an Istanbul version MID
Server, the MID Server Status is changed to
Upgrading while the upgrade is running. The
Upgrading state is similar to the Paused state. This is done to avoid potential
miscommunication between the new version of the instance and the previous version of the MID
Server during upgrade. For the upgrade to run, MID servers must be in the
Up state and must be validated.
While in the Upgrading state, you cannot resume or restart the MID
Server. However, you can perform the same actions that you can when the MID Server is in the
Paused state. After a successful upgrade, the queued output is sent to
the instance and the MID Server starts retrieving new commands to process. The status also
changes to Up.
When the instance sends the
system command to the MID Server, if
it is Down
, or if it has not been
validated, the command remains in the ECC Queue until the MID Server status changes to
. Then the command is processed.
Note: If you are using an
Istanbul instance but you are upgrading a pre-Istanbul MID Server to Istanbul, these
upgrade states are not available. They are only available for MID Servers that are already
Failed upgrades are handled differently based on the version you are upgrading to:
- Upgrade to another major release (such as Istanbul to the next full release): the status
changes to Upgrade Failed.
- Upgrade from a minor version within a release (such as Jakarta patch 1 to patch 2): the MID
Server continues using the version it is currently running. It does not perform the
upgrade and the status eventually changes to Up, assuming the MID
Server was already functioning properly.
Upgrading MID Servers in the Down state
If a MID Server is in the Down state, it cannot process the upgrade
command. When the MID Server changes to Up, it immediately checks to see
if an upgrade is necessary. If it does need to upgrade, the upgrade process starts before the
MID Server processes any other commands.
Upgrade error messages
The MID Server can display the following upgrade error messages.
Table 1. Upgrade error messages
|Unable to refresh packages
||Generic error when the error is not handled by a defined error message.
|Failed to query instance for MID Server buildstamp
||Instance is unavailable or there is a major version mismatch between the MID Server
and the instance.
|Not a valid package buildstamp
||InstanceInfo returned an assigned buildstamp that was not in the correct format, such
as a version mismatch.
|Method failed (<instance URL>) HTTP/1.1 409 Conflict with
||MID Server auto-upgrade request rejected when number of concurrent upgrades
exceeds 2. The configured number of available semaphores for MID Server upgrades
on the instance is set at 2 to prevent performance degradation.
Note: The MID
Server re-sends the request every 20 seconds until it can get the
MID Server Upgrade History
Use the MID Server Upgrade History module for troubleshooting problems with MID Server
upgrades. The module contains a record of each instance upgrade. Those records provide
step-by-step status details for each MID Server's upgrade process. If an error occurs, it is
noted in the step and a message is dynamically generated with further details. For further
information, see MID Server Upgrade