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.
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
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.
MID Server access to OCSP blocked
Firewalls and proxy configurations may block calls to the OCSP
Entrust server, which prevents the MID Server from working. You may need to change your
firewall permissions so the OCSP traffic to go through properly. For more information and
resolutions, see the HI Knowledge Base article [KB0813636].
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.
-
During an automatic upgrade, the MID Server
automatically verifies the digital signature of upgrade packages to ensure they
haven’t been tampered with. The MID Server downloads upgrade patches one by
one and stores them in the file system. After a patch is downloaded, the MID
Server verifies its digital signature and throws an exception if the verification
fails. The error will be recorded in the agent log and the MID Server issue table.
Set the property mid.log.level=trace to see detailed
verification debug messages.
-
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.
The MID Server automatically runs the pre-upgrade test before upgrading. Any errors encountered during this test
prevent the upgrade from occurring until the issues are resolved. See Upgrade the MID Server manually for instructions.
To manually verify
the signature of an installation or upgrade package, use the jarsigner tool which is
available for free with JDK. The following is the jarsigner command to initiate
the verification: Jarsigner -verify -verbose -certs -strict
<zip-file>
The output should be similar to the following example:
- Signed by "CN=ServiceNow Inc., O=ServiceNow Inc., L=Santa Clara, ST=California, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Tue Nov 05 19:55:37 UTC 2019
Timestamp digest algorithm: SHA-256
Timestamp signature algorithm: SHA256withRSA, 2048-bit key
jar verified.
The signer certificate will expire on 2021-08-09.
The timestamp will expire on 2029-03-22.
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 only available 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.
- Automatic upgrade on Linux systems from Madrid or lower to New York: the MID Server
will fail to automatically upgrade. The MID Server service must be manually reinstalled
to complete the upgrade.
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. |
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. The table
cleanup job automatically deletes issues that haven't been detected for 30 days, regardless
of their state. For further information, see MID Server Upgrade History.
