--- sourceDocument: Yokohama ServiceNow AI Platform Capabilities sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/servicenow-platform Release : - yokohama ft:locale : - en-US ft:publication_title : - Yokohama ServiceNow AI Platform Capabilities ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # MID Server upgrades # MID Server upgrades {#ariaid-title1} * Release version: Yokohama * * Updated May 11, 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 12 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 MID Server upgrades MID Server upgrades in ServiceNow can be performed either automatically or manually to ensure MID Servers run the same version as the instance. Automatic upgrades happen when the instance version changes and the MID Server detects a version mismatch. The upgrade process downloads the new MID Server package, replaces old files, and restarts the MID Server with the updated version. Manual upgrades can be triggered via the MID Server record for immediate update or to retry failed upgrades. Show full answer Show less ## Key Requirements and Considerations * **Access to ServiceNow download site:** The MID Server host must access install.service-now.com for automatic upgrades. Self-hosted environments must import installation packages manually. * **Windows-specific restrictions:** Automatic upgrades fail if the Windows Application Experience service is disabled or certain antivirus software blocks file replacement during upgrade. * **Operating system compatibility:** 32-bit Windows or Linux OS are not supported for upgrades. Linux services installed on versions Madrid or earlier may require manual service reinstallation post-upgrade. * **Firewall considerations:** Firewalls blocking OCSP traffic to Entrust and DigiCert servers can prevent MID Server operation and require configuration adjustments. ## Version Control and Upgrade Triggers The MID Server version is controlled primarily by two system properties: * **mid.buildstamp:** Indicates the instance's MID Server version, resetting on instance restart or upgrade. * **mid.version.override:** Pins all MID Servers to a single version and disables automatic upgrades; must be added manually and is cleared during instance upgrades. Additionally, individual MID Servers can be pinned to specific versions via the `mid.pinned.version` parameter in their `config.xml`. Use of override or pinned versions is generally discouraged as version mismatches can cause MID Server outages. ## Upgrade Methods and Process * **Automatic upgrade:** Triggered by the instance upgrade or hourly checks by the MID Server. Cannot modify the hourly check interval. * **Manual upgrade:** Initiated by administrators via the MID Server record in the platform, useful for immediate upgrades or retrying failed attempts. The upgrade process includes: * **Pre-upgrade checks:** Validates host requirements and blocks upgrade if critical issues are detected (can be disabled via system property). * **Package download and verification:** MID Server downloads ZIP packages from ServiceNow and verifies digital signatures to ensure package integrity. * **Extraction and replacement:** ZIP files are extracted in a temporary folder and old files in bin, lib, and jre directories are replaced with new versions. From the Rome release onward, only changed files are replaced. * **Service reinstallation:** If required (for older Linux services), the MID Server reinstalls its service during upgrade. * **Restart and cleanup:** MID Server restarts with the new version and removes temporary upgrade files. ## Logging and Troubleshooting Upgrade logs are recorded in multiple files including `agent.log`, `glide-dist-upgrade.log`, `dist-upgrade.log`, and `wrapper.log`, capturing pre-upgrade checks, downloads, extraction, and file replacement steps. Administrators can enable debug logging during upgrade by creating an `upgrade-wrapper-override.conf` file. The MID Server Upgrade History module provides detailed step-by-step records of each upgrade attempt and status, helping troubleshoot issues. Failed upgrades during file replacement cause the MID Server to remain down; failures during earlier steps result in different behaviors depending on upgrade type (major or minor). ## MID Server States During Upgrade * **Upgrading:** MID Server status changes to Upgrading to prevent communication issues between different versions during the upgrade. In this state, restart or resume actions are disabled. * **Upgrade Failed:** Indicates upgrade failure with different handling based on failure point and upgrade type. Manual intervention may be needed if the MID Server remains down. ## Additional Notes * JRE TrustStore certificates are automatically migrated during JRE updates starting from Quebec release to preserve custom certificates. * Using system properties or configuration parameters to pin versions disables automatic upgrades and may lead to version mismatches and service disruption. * Antivirus software may interfere with the upgrade process by blocking file replacements; related issues are documented for resolution. Upgrade MID Servers manually, or automatically through the instance. MID Server automatic upgrade is triggered when the instance upgrades and the MID Server no longer has the same version. The new MID Server package is downloaded from install.service-now.com, replaces the old one, and the MID Server starts with the new version. Warning: The MID Server can't auto-upgrade on a Windows host if the Windows Application Experience service is turned off. For information on the error that is displayed and instructions for re-enabling this service, see [KB0597552](https://support.servicenow.com/kb_view.do?sysparm_article=KB0597552#appex). ## MID Server upgrade requirements {#c_UpgradeAndTestMIDServer__section_u3z_xdf_1qb} 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](https://support.servicenow.com/kb_view.do?sysparm_article=KB0760123) in the Self-Hosted knowledge base. MID Server access to OCSP blocked : Firewalls and proxy configurations may block calls to the OCSP Entrust and DigiCert servers, which prevents the MID Server from working. You may need to change your firewall permissions so that the OCSP traffic goes through. For more information and resolutions, see the HI Knowledge Base article [\[KB1216223\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1216223). MID Server operating system compatibility : Upgrading Windows or Linux MID Servers with 32-bit operating systems is not supported. For supported operating systems and other host requirements, see [MID Server system requirements](https://www.servicenow.com/docs/4j~DXw_Cfdj1uyhyC10Muw "Use these minimum system requirements to allocate resources for computers hosting MID Servers."). The MID Server can't upgrade on a Windows host if the Windows Application Experience service is turned off. For information on the error that is displayed and instructions for re-enabling this service, see [KB0597552](https://support.servicenow.com/kb_view.do?sysparm_article=KB0597552#appex&_ga=2.137899701.402632408.1615226320-1555493315.1610383440). The MID Server upgrade is blocked by some antiviruses running on Windows hosts. For information on the errors and list of these antiviruses, see [KB0870329](https://support.servicenow.com/nav_to.do?uri=/kb?id=kb_article_view&sysparm_article=KB0870329). Any Linux MID Server upgrade that's service is installed under system in Madrid or lower needs to re-install the service after upgrade. If you didn't manually reinstall the service in previous upgrades and your MID Server service is still installed on Madrid or lower versions, during upgrade the MID Server automatically re-installs the service. To re-install the service MID Server needs to run as an admin user. If your MID Server upgrade needs to re-install the service, make sure that the MID Server user is admin, or you can manually re-install the service before upgrade. For information about manually re-install the service, see [KB0821436](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0821436). ## When does the MID Server need to upgrade {#c_UpgradeAndTestMIDServer__section_o1l_n2f_1qb} Any MID Server with a version different from the instance version needs to upgrade. The following two system properties control the version of 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](https://www.servicenow.com/docs/access?context=t_AddAPropertyUsingSysPropsList&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US). {#c_UpgradeAndTestMIDServer__ul_pdt_r2f_1qb} 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. 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. In addition to mid.version.override, the MID Server version can also be controlled with the configuration parameter mid.pinned.version which pins the MID Server to a specific version.To pin a MID Servers, set the mid.pinned.version parameter with the name of that version in the config.xml file of each MID Server. Use the format \-mm-dd-yyyy. This setting overrides the property setting for the pinned MID Server version. For instructions, see [Add a MID Server parameter](https://www.servicenow.com/docs/9bf6AMU0YzFSeKaPniMXlQ#mid-server-parameters "Parameters control the behavior of a particular MID Server and have lower precedence than MID Server properties."). The value set in this parameter is not affected by an upgrade. Warning: Using mid.version.override and mid.pinned.version is not recommended. The different versions on the MID Server and instance can cause outage issues on the MID Server. ## Upgrade methods Automatic : Automatic upgrade can be triggered by the instance or the MID Server itself. This functionality is available by default. Automatic upgrade occurs: * When the instance is upgraded and the MID Server for that version is different than the version currently on the MID Server. The instance sends autoUpgradesystem command to the connected MID servers. * Every hour, the MID Server checks with the instance to see if there is a different version available for upgrade. You cannot modify this time period. Note: Hourly version checks can occur at different times because they are based on when each MID Server started. During an instance upgrade, all connected MID Servers receive the upgrade command at the same time and can attempt to upgrade concurrently. {#c_UpgradeAndTestMIDServer__ul_gyx_3ff_1qb} 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. See [Trigger MID Server upgrade](https://www.servicenow.com/docs/qT6fgXPWhBUgda1kcag3jg "MID Servers automatically upgrade to match the instance build the next time they communicate with the instance after an instance upgrade. Use this procedure only if you want to upgrade a MID Server immediately or retry the upgrade after an Upgrade failed status.") for instructions. ## Upgrade process {#c_UpgradeAndTestMIDServer__section_tl1_prm_1qb} 1. Pre-upgrade Check:Before starting the actual MID Server upgrade process, the MID Server runs a set of tests to make sure that the host machine meets the minimum requirements. 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. See [MID Server pre-upgrade check](https://www.servicenow.com/docs/NrZ9VAaESY5mwoAlduQg1Q "Prior to an upgrade, the MID Server runs tests to identify issues that could cause the upgrade process to fail or result in a MID Server outage.") for more information. 2. Download the packages:The MID Server downloads upgrade packages from install.service-now.com. These packages are in zip format and are downloaded to the agent folder in the package/incoming folder. 3. Digital Signature Verification After downloading every package, MID Server verifies the digital signature of the package. It throws an exception if the verification fails. The error will be recorded in the agent log and the MID Server issue table. If the packages are downloaded and replaced manually you can verify the signature manually. 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 ` 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. 4. Extracting Zip Files:After downloading all required packages, the MID Server extracts the zip files. * Before Rome: The zip files are extracted in a folder under the operating system defined temporary folder. The folder name is a randomly generated number. The operating system temporary folder is specified by system property java.io.tmpdir. On a UNIX host, the value for this property is typically is /tmp or /var/tmp. * From Rome onward: The MID Server avoids using operating system defined temporary folders during MID Server upgrade. The zip files are extracted in a folder in the work/upgrade_temp folder under the agent folder. The folder name format is a randomly generated number. If you want to switch to the previous behavior and use an operating system defined temporary folder you can add mid.upgrade.use_os_temp_folderto MID Server's config.xml file and set it to true. To switch the behavior for all MID Servers, you can add it to the MID Server property \[ecc_agent_property\] with MID Server field blank. {#c_UpgradeAndTestMIDServer__ul_ll5_msm_1qb} Note: If you are using [KB0747569](https://support.servicenow.com/nav_to.do?uri=/kb?id=kb_article_view&sysparm_article=KB0747569) to change thejava.io.tmpdirand you want to keep it for future upgrades from Rome, set mid.upgrade.use_os_temp_folderto true after upgrading to Rome. If mid.upgrade.use_os_temp_folder is not set to true then java.io.tmpdir isn't applied during the MID Server upgrade and the folder under agent\\work\\upgrade_temp will be used. 5. Replace old packages with the upgraded packages:After downloading and extracting the upgrade packages, the MID Server replaces old files with the new files and starts with the new version. To replace the packages, the MID Server starts a process named ServiceNow AI Platform Distribution Upgrade and shuts down. ServiceNow AI Platform Distribution Upgrade waits for the MID Server to shut down properly, then replaces the required files as follows: * Before Rome:The process deletes all files and folders in the bin, lib and jre folders and copies the new files into those folders. * From Rome onward: The process replaces the files in the bin, lib and jre only if the new version of the file is different from the old version. ServiceNow Platform Distribution Upgrade does not clean the upgrade files and the unchanged files are kept. {#c_UpgradeAndTestMIDServer__ul_kwc_htm_1qb}If the reinstalling service was required as a part of MID Server upgrade, ServiceNow Platform Distribution Upgrade reinstalls the service before starting the MID Server. For more information refer to [KB0821436](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0821436). Note: If the MID Server upgrade fails in this step the MID Server stays Down. Some anti-viruses block the file replacement in this step. For more information refer to [KB0870329](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0870329). 6. Start the MID Server:After replacing all required files with the new version, the ServiceNow AI Platform Distribution Upgrade starts the MID Server. When the MID Server comes Up with the new version, it cleans up all temporary folders used to extract the upgrade files. {#c_UpgradeAndTestMIDServer__ol_jzk_hsm_1qb} ## Upgrade log messages {#c_UpgradeAndTestMIDServer__section_b2s_xtm_1qb} The MID Server log messages are available in the following log files: * Pre-upgrade check log messages are available in agent.log file under agent/logs folder. The message Performing pre-upgrade validation tests. indicates that the pre-upgrade check has started. If all mandatory tests are passed, the message Pre-upgrade validation tests successful. Continuing with upgrade process. indicates the end of the pre-upgrade check. * Log messages for downloading missing files are also available in agent.log. Every package download starts with Downloading package to PACKAGENAME.ZIP from https://install.service-now.com/ PACKAGEINFO message. The download progress and the size of downloaded file is monitored in the log. After downloading every package, Package was successfully downloaded from https://install.service-now.com/ PACKAGEINFO indicates the successful download. * Extracting the zip files is the last step available in the agent.log. The message Upgrading MID server indicates the start of this step, and the message Extracting package PACKAGE.ZIP to EXTRACT_TMP_FOLDER is shown for every package extraction. When all required zip files are successfully extracted, the MID Server starts the ServiceNow AI Platform Distribution Upgrade process and the message Stopping MID server. Bootstrapping upgrade shows the end of this step before MID Server goes Down. {#c_UpgradeAndTestMIDServer__ul_c2f_ztm_1qb} ServiceNow AI Platform Distribution Upgrade logs include log messages for the process start up and for replacing files during the MID Server upgrade. The upgrade log messages are placed between the messages \*\*\*\*\*\*\*\*\*\*\*UPGRADE MAIN LOGIN START\*\*\*\*\*\*\*\*\*\*\* and \*\*\*\*\*\*\*\*\*\*\*UPGRADE MAIN LOGIN END\*\*\*\*\*\*\*\*\*\*\*. ServiceNow AI Platform Distribution Upgrade log messages can be found in the following log files: * In the glide-dist-upgrade.log file under temp extract folder. This file is available in upgrade-wrapper/logs folder under temp extract folder. This log file includes process log messages and upgrade log messages. * In the dist-upgrade.log file in agent\\logs folder. This file only includes the upgrade portion of log messages. If there was some issue with the process startup you need to look at glide-dist-upgrade.log. * In wrapper.logunder agent\\logs folder. After replacing files, ServiceNow AI Platform Distribution Upgrade appends glide-dist-upgrade.log to the wrapper.log file. {#c_UpgradeAndTestMIDServer__ul_z1h_k5m_1qb} ## Update the wrapper configuration with upgrade-wrapper-override.conf {#c_UpgradeAndTestMIDServer__section_bvp_ybl_fzb} The wrapper configuration for glide-dist-upgrade can be updated using a upgrade-wrapper-override.conf file. Create a file named upgrade-wrapper-override.conf in the agent/conf folder. Any configurations in the upgrade-wrapper-override.conf are used during the upgrade process. By modifying the configuration with upgrade-wrapper-override.conf, debug logs can be enabled at the dist-upgrade wrapper level and changes can be tested. For example, the default timeout may not be long enough for certain JVM level commands. The timeout can be increased with upgrade-wrapper-override.conf for the dist-upgrade wrapper configuration. ## MID Server states {#c_UpgradeAndTestMIDServer__section_t1p_jc4_1qb} Upgrading : The MID Server status is changed to Upgrading while the upgrade is running. The Upgrading state is similar to the [Paused](https://www.servicenow.com/docs/Q390rqi9OVkNNTzq97iJwA#t_PauseTheMIDServer "Pause the MID Server to temporarily prevent it from polling the ECC Queue for work or sending Discovery results back to the instance.") state. This is avoids potential miscommunication between the new version of the instance and the previous version of the MID Server during upgrade. 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. 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. Upgrade Failed : The MID Server handles upgrade failures differently based on which step fails: * Failure during the pre-upgrade check or package download/extract step: The outcome depends on the type of upgrade: * Major release upgrade (for example, Istanbul to the next full release): The status changes to Upgrade Failed. * Minor version upgrade (for example, 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 before the upgrade attempt. {#c_UpgradeAndTestMIDServer__ul_e2h_csy_yjc} * Failure during the package replacement step: If the upgrade fails while replacing the old packages with the new ones, the MID Server status stays Down. {#c_UpgradeAndTestMIDServer__ul_k4q_rc4_1qb} ## MID Server upgrade history {#c_UpgradeAndTestMIDServer__section_xml_lly_qhb} 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](https://www.servicenow.com/docs/dnGwWIKRdou8_tuQm9q5lA "Use this module to troubleshoot errors that occur during the MID Server upgrade process. The MID Server Upgrade Histories table contains a record of each instance upgrade. The MID Server Upgrade Stages table shows the status of each MID Server and its upgrade progress, including any errors encountered."). ## JRE TrustStore certificate migration during JRE updates {#c_UpgradeAndTestMIDServer__section_nc5_cs5_4nb} For JRE updates after upgrading to Quebec, the MID Server migrates existing self-signed certificates in the JRE TrustStore to the new JRE version's TrustStore. When these certificates are migrated, their aliases are prepended with the string "snc_". In order for a certificate to be migrated it must be: * an X509 certificate * certificate standard v3 * have the basic constraint extension set to false (i.e. it is not CA issued) {#c_UpgradeAndTestMIDServer__ul_wb3_fs5_4nb} The MID Server identifies when a JRE upgrade is about to take place and begins the migration process. Before the migration, the MID Server creates a backup of the original TrustStore as a fall-back in the event of failure. If there is a failure, the backup TrustStore can be manually restored. * **[MID Server pre-upgrade check](https://www.servicenow.com/docs/NrZ9VAaESY5mwoAlduQg1Q)** Prior to an upgrade, the MID Server runs tests to identify issues that could cause the upgrade process to fail or result in a MID Server outage. * **[Pinning a MID Server to a specific version](https://www.servicenow.com/docs/zVDyyReZ79sHQcd3DSHNJQ)** 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. * **[Trigger MID Server upgrade](https://www.servicenow.com/docs/qT6fgXPWhBUgda1kcag3jg)** MID Servers automatically upgrade to match the instance build the next time they communicate with the instance after an instance upgrade. Use this procedure only if you want to upgrade a MID Server immediately or retry the upgrade after an Upgrade failed status. **Related concepts** * [MID Server dashboard](https://www.servicenow.com/docs/CTke3Lqzsh8kfktMWhKK8A "The MID Server dashboard is a central place for MID Server users to monitor ongoing operations. The dashboard consists of reports and gauges that display information from the MID Server Status table.") * [MID Server File Cleaner](https://www.servicenow.com/docs/UOs_PAj0ZzeS_1dGYhQ26A "A monitor thread runs in the MID Server to clean up old files, to keep the size and quantity of files within the install folder manageable, and to prevent performance issues with the MID Servers.") * [MID Server privileged commands](https://www.servicenow.com/docs/jHZdSShGx_wDoFToSvoktw#c_PrivilegedCommandsForMIDServer "To discover certain information on a host server, the MID Server must run SSH commands with higher privileges. The platform provides default privileged commands for the MID Server to use and the ability to add additional commands to the system.") **Related tasks** * [Manually start, stop, and restart a MID Server](https://www.servicenow.com/docs/IYs5fBPqVEOuqstZJckkXw "If you did not start the MID Server at the end of the installation procedure, you can manually start the MID Server.") * [Set the MID Server JVM memory size](https://www.servicenow.com/docs/KrWcjHIVVy4FOFmLc1ipGA "The MID Server starts with a default JVM memory allocation, but you can modify this setting in the configuration file.") * [Pause the MID Server](https://www.servicenow.com/docs/Q390rqi9OVkNNTzq97iJwA#t_PauseTheMIDServer "Pause the MID Server to temporarily prevent it from polling the ECC Queue for work or sending Discovery results back to the instance.") **Related reference** * [MID Server system requirements](https://www.servicenow.com/docs/4j~DXw_Cfdj1uyhyC10Muw "Use these minimum system requirements to allocate resources for computers hosting MID Servers.") * [Resolving MID Server issues](https://www.servicenow.com/docs/2mQkw_AXv_5F5KtFiT9UwA "Troubleshoot problems with the MID Server to find solutions. Monitor the MID Server to receive alerts about issues as they occur. Troubleshooting procedures exist to resolve specific problems with the MID Server. The Knowledge Base on Hi contains several articles to help you troubleshoot MID Server issues.") * [MID Server properties](https://www.servicenow.com/docs/kCZI01CdDboQJ~Alkf3MFg#r_MIDServerProperties "Properties control the behavior of all MID Servers or a particular MID Server.") * [MID Server parameters](https://www.servicenow.com/docs/9bf6AMU0YzFSeKaPniMXlQ#mid-server-parameters "Parameters control the behavior of a particular MID Server and have lower precedence than MID Server properties.") * [MID Server Configuration Parameter settings and priority](https://www.servicenow.com/docs/zmIKyIToc_JohWVTG6CHNQ "The MID Server's settings reside in multiple tables and the MID Server prioritizes them in a set order. MIDConfigParameter must be defined with the correct type-style builders.") * [MID Server protected records and reserved characters](https://www.servicenow.com/docs/R_UORSGTsWLLds5WDthYMg "Some MID Server records cannot be altered. Certain special characters are pre-defined in XML and cannot be used in passwords.") * [MIDSystem methods](https://www.servicenow.com/docs/8sGrXh3ukCa4vzdmJEPzVw "MIDSystem variables (referred to by the variable name ms.) provide a variety of methods to get information about the MID Server.") * [MID Server heartbeat](https://www.servicenow.com/docs/Cx2YLLAd_cUQAwGVk5QRIw "The instance checks the MID Server for a response every 5 minutes, using a synthetic transaction monitoring system.")