Pinning a MID Server to a specific version

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Pinning a MID Server to a specific version

    This guide explains how ServiceNow customers can control MID Server versions by pinning them to specific releases. You can either pin all MID Servers in your environment to a single version via system properties or configure individual MID Servers to use specific versions through configuration parameters.

    Show full answer Show less

    However, it is generally recommended not to pin MID Servers to specific versions to avoid version mismatches and potential functionality issues. Letting the instance manage MID Server versions helps maintain compatibility and smooth operations.

    Version Control Properties

    Two key system properties govern MID Server version control for all MID Servers:

    • mid.buildstamp: This property identifies the MID Server version using a date-time stamp format (mm-dd-yyyy-hhmm), appended with the release name and patch info. MID Servers check this property hourly for version updates. It resets to the default instance-matched version on instance restarts or upgrades, so manual changes are lost at those events. This property is not visible by default and generally should not be manually configured.
    • mid.version.override: This property allows pinning all MID Servers to a single, specific version, disabling automatic upgrades. It is not visible by default and must be manually added to the system properties table. When set, MID Servers prioritize this override value over mid.buildstamp during their hourly version checks. This override persists across instance restarts but is cleared during upgrades to reset MID Servers to the default version.

    Version Control Configuration Parameter for Individual MID Servers

    To pin specific MID Servers to a desired version independently of system properties, you can set the mid.pinned.version parameter in the config.xml file of each MID Server. The version should be specified in the format <version>-mm-dd-yyyy. This setting takes precedence over system properties for that MID Server.

    The MID Server checks the pinned version every 20 minutes or upon restart, applying the pinned version accordingly. Unlike system properties, this parameter is not reset during instance upgrades, allowing persistent control over the MID Server version.

    Practical Considerations

    • Pinning MID Servers can lead to version mismatches with your ServiceNow instance, potentially causing broken functionality.
    • Use mid.version.override cautiously to pin all MID Servers, understanding it disables automatic upgrades and resets on upgrades.
    • Use the mid.pinned.version parameter for finer control on individual MID Servers, particularly when you need a stable version unaffected by upgrades.
    • Always weigh the need for pinning against the risks of desynchronization and maintenance overhead.

    You can pin all the MID Servers in your environment to a specific version by setting a system property, or you can configure specific versions for individual MID Servers.

    Note:
    Under most circumstances, do not pin the MID Server to a specific version. Pinning the MID server can make it out of sync with the instance, and lead to broken functionality. Instead, let the instance determine which MID Server version to use.

    Version control properties

    These system properties control the version for all MID Servers:
    • mid.buildstamp: Identifies the MID Server version with an identifier based on the date of the build. This property uses the format of mm-dd-yyyy-hhmm. The MID Server checks for version information hourly. If no override version is configured, the MID Server looks at the mid.buildstamp property for the version to use. This property resets itself to the default version (the version that matches your instance version) when the instance is restarted or upgraded, so any user changes are lost at that time. The system appends the release name and patch information to the date and time format.
      Warning:
      This property is not visible by default and should not be configured.
    • mid.version.override: Sets an override condition for the current version for all MID Servers in your environment. This action pins the MID Servers to a single version and disables the automatic upgrade feature. This property is not visible in the base system and must be added to the System Property [sys_properties] table when it is set. For details, see Add a system property.
      When the MID Servers check the version each hour, they look at the mid.version.override property first. If this property is empty, the MID Servers get their version information from the mid.buildstamp property. If an override version is configured, the MID Servers use this value and ignore the version information in the mid.buildstamp property. This override value remains when the instance is restarted and is passed to the MID Servers.
      Important:
      The value in the mid.version.override property is cleared during an upgrade, which forces the MID Server to reset itself to the version in the mid.buildstamp property.

    Version control configuration parameter

    To pin specific MID Servers on a desired version, set the mid.pinned.version parameter with the name of that version in the config.xml file of each MID Server. Use the format <version>-mm-dd-yyyy. This setting overrides the property setting for the pinned MID Server version. The MID Server version is checked every 20 minutes or whenever the MID Server restarts, at which point the pinned version is applied. For instructions, see Add a MID Server parameter.
    Note:
    The value set in this parameter is not affected by an upgrade.