MID Server Manual Upgrade Steps, for issues where the expected Auto-Upgrade of the MID Server fails, or to repair a corrupted installation or missing files.
This procedure should be considered a last resort, and we would normally request you open a support Case in HI in order for the cause to be identified, as you may have to keep doing this on every upgrade if a mis-configuration causing it remains.
- Save logs and other details of the failed upgrade, so that it may be possible to find the cause later on.
- Gather the required information and configuration settings:
- Instance Username and Password, for the instance user that the MID Server logs in as.
- Proxy server information if used, including the proxy server, username and password.
- Host server running the MID Server, the install folder and the Service name for it.
- Have remote desktop access as an administrator to the host server
- Backup the following files:
- Download the current full MID Server package from your ServiceNow instance
- Navigate to MID Server - Downloads
- Select the link for your MID Server host's platform to download. If unsure, use the 64 bit link.
- Copy the ZIP file to the MID Server host.
- Extract the ZIP file to a temporary folder. Ensure there are no errors extracting the ZIP file.
- If you are blocked from downloading from install.service-now.com, then enable system property: mid.download.through.instance=true
- Make sure there are no scheduled jobs happening using the MID Server during the procedure especially if performing it in a PRODUCTION instance. Checking that no ECC Queue output records for the MID Server are currently in Ready or Processing state is also advised.
- Stop the Mid Server service.
- Go to the existing MID Server installation folder, and rename the existing 'agent' folder and move it to a different location.
- Use a name such as 'agent_old-do_not_run' or similar so there is no confusion in future.
- If this is not possible because of files still in use by the operating system, then set the Service startup to Manual, and restart the server to free up the files.
- Move the recently extracted 'agent' folder to the original agent folder's location.
- Manually update the following files based on the information from the backup files, and credential information gathered earlier
- url, mid.instance.username, mid.instance.password, name
- mid_sys_id and keypairs.mid_id
- Other likely custom values:
- mid.proxy.use_proxy, and the various mid.proxy.* parameters, if a Proxy is used between the MID Server and Instance
- threads.max, threads.expedited.max, threads.interactive.max if different from the defaults
- instance.date.format if different from the default
- wrapper.name, wrapper.displayname.
Note: These need to match the existing Windows Service name and display name. If the upgrade failed due to a mismatch, then that can be corrected now to match the windows service.
- wrapper.name, wrapper.displayname.
- Create a "keystore" folder under the "agent" folder, and copy the "agent_keystore.jks" file into it.
- If you had a custom cacerts file, with SSL Certificates added to it, then copy the backup "cacerts" file over the empty one in the "agent\jre\lib\security" folder
- Start the existing MID Server service.
- Check the MID Server from the instance if the Status is UP.
- Validate the MID Server if necessary.
If this procedure fails then you may need to install a new fresh MID Server, and then set up the Capabilities/IP Ranges/Applications similar to the broken MID Server, and then reconfigure features and jobs and clusters that used the broken MID Server to use the new one instead. Follow the usual fresh installation steps in the documentation:
Download the MID Server Files
MID Server Installation