NOTE: The resolution described below in this article is only required until you have upgraded to London or later. Once the MID Server is running London or later, the instance can then act like a kind of proxy and so direct access to the install server is no longer necessary. The MID Server will always have access to the instance, so this is no longer an issue.

Once you have got your MID Servers running London or later, please set/add this system property to avoid this in future:



When an instance is upgraded, the MID Server needs to upgrade itself to match and needs to Download Upgrade Files from and if it does not have access, it fails to upgrade. The automatic Test MID Server connectivity feature will check for and notify you if the MID Server can't.

Warning: A MID Server on the wrong version can cause code and data mismatches between MID Server and instance, potentially causing:

  • the MID Server to not process commands sent it by the instance
  • the instance to not process data coming back from the MID Server


In the following situations, your MID Server computer has no access to the install server and cannot auto-upgrade itself. You should try to resolve these issues internally first:

  • The instance is on-premise and installed inside the customer network (with no Internet access), and the MID Server also has no internet access at all.
  • The instance is hosted in our datacenter, but although the MID Server does have access to the instance, you have not yet arranged for it to have access to our upgrade server:


MID Server Agent log including:

Jakarta and Kingston:

AutoUpgrade.3600 Performing pre-upgrade validation tests.
AutoUpgrade.3600 Downloading from
AutoUpgrade.3600 WARNING *** WARNING *** Method failed: ( null with code: 0
Istanbul and earlier, there is no pre-upgrade check:
AutoUpgrade.3600 Downloading package to from
AutoUpgrade.3600 WARNING *** WARNING *** Method failed: ( null with code: 0

This manual procedure fools the MID Server into thinking it has downloaded the files itself already, allowing it to upgrade itself in the normal way, and if necessary must be done for every MID Server after every upgrade or patch of every instance, without fail. 

1) Find the filenames from the Agent log:

On the MID Server computer, check the latest 'AutoUpgrade' or 'StartupSequencer' thread entries in the Agent Log for the "Missing:" ZIP file names:
<install folder>\agent\logs\agent0.log.0

StartupSequencer Packages refreshed.
StartupSequencer Current packages:
StartupSequencer   Installed: [,]
StartupSequencer   Assigned: [,,]
StartupSequencer   Missing: [,,]
StartupSequencer   Downloaded: []

In that example, the MID Server is still Kingston Patch 0, even though the instance is already upgraded to Kingston Patch 1, and the missing files in this example are:

2) Next figure out the full URL for those files.

Since Geneva, the filename is made up of:
<Upgrade file>.<MID Buildstamp>.<platform>.<architecture>.zip
and the URLs also take a common form.<file type>/<MID Buildstamp date>/<File name>

In my example the filenames are rearranged to become these URLs:




3) Download these files manually on another computer that has internet access and then copy those ZIP files to the MID Server folder:

<install folder>\agent\package\incoming

Note: The file names and URLs will be specific to a particular version of the platform. In this example it is Kingston Patch 1, but the same process applies to all versions.


4) Upgrade the MID Server

At this point you can wait for the AutoUpgrade thread to run again (it is on a 1 hour interval) or restart the MID Server service to force it to upgrade now.

The next time the AutoUpgrade thread runs, Downloaded: shows the files present in the <install folder>\agent\logs\agent0.log.0 log. It then goes ahead and does the upgrade.

StartupSequencer   Downloaded: [,,]

You can then re-use the downloaded files for any other MID Servers that are also connecting to the same instance.


Article Information

Last Updated:2019-05-21 11:55:36