Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

MID Server upgrade

Log in to subscribe to topics and get notified when content changes.

MID Server upgrade

MID Servers are automatically upgraded through the MID Server host computer. You can also manually upgrade each MID Server.

Warning: 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 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 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:
  • 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.
  • 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.

Upgrade methods

  • 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 autoUpgrade system command to the MID Server, if it is Down or Paused, or if it has not been validated, the command remains in the ECC Queue until the MID Server status changes to Up. 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 on Istanbul.

Failed upgrades

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
Message Description
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 code: 409 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 semaphore.