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.

There are several potential causes for a MID Server installation becoming corrupted or for an automatic upgrade to fail. Copying the agent0.log.0 and wrapper.log files from the mid server's agent\logs folder, plus the upgrade-wrapper.log file from the temp folder if the upgrade service failed, will usually allow a specific PRB to be identified from the errors and logs seen. KB Articles specific to those PRBs may have less destructive workaround or ways to fix the MID Server so that it doesn't happen again.

Some of these causes can be resolved with this simple method, which can save a lot of time:
KB0779816 How to continue a MID Server upgrade after it has crashed in the middle of the ServiceNow Platform Distribution Upgrade service, leaving the MID Server Down and the Service not running

1. Save logs and other details of the failed upgrade, so that it may be possible to find the cause later on.
2. 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
3. Backup the following files:
   
   • agent\config.xml
   • agent\conf\wrapper-override.conf
   • agent\jre\lib\security\cacerts
   • agent\keystore\agent_keystore.jks
     
     • We have seen in some cases that if this file is also copied over a MID server issue appears saying "Could not decrypt file discovery whitelist after sync" after the restore. 
     • In such as case, after the rest of this restore process is completed do the following:
       
       • 1) Stop the mid server service on the host machine, deleted the agent\keystore folder and start the MID server service.
       • 2) The Keystore folder will be created automatically when the service is started.
       • 3) Now login to the ServiceNow instance and validate the mid server.
       • 4) Wait for 2-5 minutes the error "Could not decrypt file discovery whitelist after sync" should be gone from "MID SERVER ISSUE TAB".
     • If you so choose, you can not copy this file and then you will have to validate the MID after the rest of the manual restore is completed.
       
4. 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

1. 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.
2. Stop the Mid Server service. 
3. 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.
4. Move the recently extracted 'agent' folder to the original agent folder's location.
5. Manually update the following files based on the information from the backup files, and credential information gathered earlier
   
   • config.xml
     
     • 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
   • conf/wrapper-override.conf
     
     • 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.
6. Create a "keystore" folder under the "agent" folder, and copy the "agent_keystore.jks" file into it.
7. 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
8. Start the existing MID Server service. 
9. Check the MID Server from the instance if the Status is UP.
10. 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