MID Servers are automatically upgraded through the MID Server host computer. You can also
manually upgrade each MID Server.
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
install.service-now.com download site, you must import the MID
Server installer package into your network manually and then transfer it to your MID
Server host machine. For
instructions, see KB0760123 in the Self-Hosted knowledge base.
These system properties control access to the MID Server download site:
- mid.download.through.instance: Enables the MID Server download
through the instance. This property is set to true for all new
instances and sends all auto-upgrade requests through the instance. For instances
upgraded from Kingston or earlier, the property is set to false
which retains the previous behavior of sending upgrade requests from the MID Server
host. To configure MID Server auto-upgrades through the instance, add this property to the System Property [sys_properties]
table and set it to true.
- concurrent.dist.download: Sets the number of concurrent MID
Server auto-upgrades permitted by the instance. The default value of this property is 2,
which allows the MID Server to use 2 of the 4 semaphores available on the instance for
upgrading. If your instance has more than 4 INT semaphores, you can increase the value
in this property to allow more concurrent upgrades.
- 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 available only 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