Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Advanced MID Server configuration

Log in to subscribe to topics and get notified when content changes.

Advanced MID Server configuration

There are several advanced options available for you to customize and configure the MID Server.

Enable script file synchronization for Windows browser security

Windows Internet Explorer enhanced security blocks downloaded files that it determines are potentially dangerous.

Enhanced security in Windows browsers, such as Internet Explorer, blocks downloaded files that it determines are potentially dangerous. This would block files downloaded for use by the MID Server. You would need to unblock each file manually through the browser.

To get around this issue, use file synchronization. File synchronization requires you to proactively take script files from your instance and save them on the MID Server. The files on the instance and the MID server stay synchronized, but there is no longer any need for the MID Server to download the whole file. File synchronization also protects any updates you make in those script files from being overwritten during the upgrade of an instance.

Script files synchronized with the MID Server are stored on the instance in the MID Server Script File [ecc_agent_script_file] table, which you can access in the MID Server > Script Files module.

When the MID Server first connects to the instance, the instance creates a directory called \scripts in the MID Server root. The instance then creates a parent directory in the path \scripts\<parent name> using definitions from the ecc_agent_script_file table. Finally, the instance creates the script files themselves inside the parent directory using the records from the ecc_agent_script_file table.

The record for the parent directory looks like this:

The instance creates each script file in the parent directory on the MID Server using the record Name from the ecc_agent_script_file table as the file name and the Script field payload as the file contents. A script file record looks like this:

The synchronization of the script file continues to work as if the script was manually added to the form.

See Attach a script file to a MID Server for instructions on how to attach a script file.

Note: The MID Server Script File [ecc_agent_script_file] table is domain separated. You can create versions of these policies that only a MID Server from the same domain can use. For instructions, see Set up domain separation for MID servers.

Attach a script file to a MID Server

Attach a script file to a MID Server to keep script files in synch with the instance without having to download the file. Do this when your browser security settings are blocking the downloading of files that your MID Server needs from the instance.

Before you begin

Role required: admin

About this task

You can attach multiple files, but the last attached file gets synchronized to the MID Server. If you delete the attachment, the script file becomes inactive, and the synchronized file is deleted from MID Server.


  1. Navigate to MID Server > Script Files.
  2. Open the file to which you would like to attach the script file, or click New to create a new file.
    Note: The script file attachment name must match the MID Server script file name, since the record can contain other attachments.
  3. Select Use attachment, and then click the paperclip icon to add the attachment.

    When Use attachment is checked, an attached script file overrides the script contained in the Script field. If this check box is cleared, the script in the Script field is used instead of the attachment.

    The script file attachment name must match the MID Server script file name, since the record can contain other attachments.

  4. Click Update to initiate the synchronization process.
    Ensure that the file name matches the script name.
    Note: If you receive the error message: File type not permitted or mime type does not match the file content, request that your administrator turn off mime type validation on attachments. The system property controls this setting.

Configure a MID Server for Service Analytics RCA

To activate the Service Analytics root cause analysis (RCA) feature, configure at least one dedicated MID Server with the ServiceAnalytics as a supported application, and with the RCA capability. To ensure uninterrupted services, it is recommended that you also configure a failover MID Server cluster for RCA.

Before you begin

If the Domain Support - Domain Extensions Installer plugin is activated, then you can configure a dedicated MID Server with the RCA capability, per domain. In this case, RCA for a business service is done on the MID Server that is in the same domain as the business service. Otherwise, a MID Server from the global domain is used.
Table 1. Hardware requirements
Component Requirement
  • Minimum: 4 GB
  • Recommended: 8 GB
  • Minimum: Either of the following:
    • Core 2+
    • Xeon processor with a speed over 2 GHz
  • Recommended: Quad-core
Disk space (for 100 discovered services)
  • Minimum: 8 GB
  • Recommended: 10 GB
Table 2. Software requirements
OS Supported OS versions Additional requirements
Windows 32-bit and 64-bit versions:
  • Windows 2008 R2
  • Windows Server 2012 R2
  • Windows Server 2016
For either version of the OS:
  • Red Hat Enterprise Edition Linux 6.6 or later
  • CentOS Linux 6.6 or later

32-bit or 64-bit version of the MID Server

Role required: admin

About this task

The RCA MID Server supports the Service Analytics RCA process by hosting the RCA Learner and the real-time RCA query handler. On the RCA MID Server, the system builds models that support responses to root cause queries. The learner data on the RCA MID Server persists by default for a maximum of 90 days.

By default, the MID Server is set up as a dedicated MID Server for Service Analytics RCA, and an attempt to add additional supported applications to the same MID Server is prevented. It is recommended that Service Analytics Metrics is also implemented with its own dedicated Metrics MID Server. These recommendations ensure high level of performance. However, if needed, you can modify this default behavior and configure the RCA MID Server or the Metrics MID Server with additional supported applications. For information about modifying the behavior of the ALL option when selecting supported applications, see Configure applications included in ALL Applications.


  1. Ensure that the MID Server is validated.
    For more information, see Validate the MID Server.
  2. Navigate to MID Server > Servers.
  3. Double-click the MID Server that you want to configure as an RCA MID Server.
  4. Add the ServiceAnalytics application:
    1. At the center of the MID Server form, click Supported Applications.
    2. In the Supported Applications section click Edit.
    3. In the slushbucket select ServiceAnalytics and click the > add button.
    4. click Save.
    If the MID Server needs to support ServiceAnalytics as well as one or more other applications, you can modify the definition of the ALL option to include these applications, and then select ALL in the slushbucket. ALL is the only option to which it is valid to add the ServiceAnalytics option. Performance might be compromised with these settings.
  5. Add the RCA capability:
    1. At the center of the MID Server form, click Capabilities.
    2. In the Capabilities section click Edit.
    3. In the slushbucket select RCA and click the '>' add button.
    4. click Save.
  6. Click Update.


The RCA MID Server is automatically configured with a Discovery IP range set to

What to do next

Create a failover cluster for RCA. In this cluster, add the MID Servers that were configured for RCA. For more information, see Configure a MID Server cluster.

MIDSystem methods

MIDSystem variables (referred to by the variable name ms.) provide a variety of methods to get information about the MID Server .

Method summary Description
log(String message) Logs the given message with a standard prefix to indicate that the message was generated by JavaScript.
getConfigParameter(String parameter name) Returns the value of the named configuration parameter.
include(String script include) Include the MID Server script include with the given name into the current context.
getName() Returns the name of the MID Server.
getSysID() Returns the sys_id of the MID Server.
toJavaScript(Object) Converts the given Java object into the equivalent JavaScript object.

This example writes a message to the log:

ms.log('Attempting to log in with user: ' + this.getParameter('user'));

Synchronize a JAR file to MID Servers

You can upload a JAR file to an instance and synchronize it to all MID Servers, or write custom probes that use the synchronized JAR file.

Before you begin

Role required: admin, agent_admin
The MID Server JAR File [ecc_agent_jar] table is domain separated. You can create versions of these policies that only a MID Server from the same domain can use. For instructions, see Set up domain separation for MID servers.
Caution: Synchronizing a JAR file with this procedure causes all MID Servers connected to the instance to restart automatically.


  1. Navigate to MID Server > JAR Files.
  2. Click New.
  3. Complete the following fields:
    • Name: A unique and descriptive name for identifying the file in the instance.
    • Version: A version number for the file, if one is available.
    • Source: Location of the JAR file for reference purposes. Source information is not used by the system.
    • Description: Short description of the JAR file and its purpose in the instance.
  4. Click the paper clip icon in the banner.
  5. In the Attachments dialog box, click Browse and select the file you want to attach.

    The platform attaches the JAR file to the record and restarts the MID Servers to synchronize the file. It is not necessary to update the record to attach the file.

Set the MID Server JVM memory size

The MID Server starts with a default JVM memory allocation, but you can modify this setting in the configuration file.

Before you begin

Role required: admin

About this task

In the base system, the MID Server JVM memory is set to 1024MB, which is configured in the \agent\conf\wrapper-override.conf file in the MID Server installation directory. This setting might not be appropriate for the way your organization uses the MID Server. If you want the MID Server to work harder, allocate more resources to it. If the MID Server is located in a small branch office and runs in an environment where memory allocation is shared between a print server, mail server, or web proxy server, the allocation might have to be reduced.
Note: For a complete list of minimum MID Server requirements, see MID Server system requirements.


  1. Open the \ServiceNow\<MID Server name>\agent\conf\wrapper-override.conf file in a text editor.
    For more information about this file, see Installing Multiple MID Servers on a Single System.
  2. Locate the following lines in the file:
    # OPTIONAL: Maximum Java Heap Size (in MB)#
  3. Edit the memory allocation.
  4. Remove the comment tag (#) from the memory allocation parameter.
  5. Save the file.
  6. Restart the MID Server service.

Set MID Server thread use

If the MID Server is running on a host containing many other programs that must compete for CPU time, fewer threads than the default of 25 might be necessary.

Before you begin

Role required: admin

About this task

You can set the MID Server to use as few as 5 threads without issues. If the MID Server needs more speed, and the host is powerful enough or lightly loaded with other programs, raise the thread setting. The thread limit depends on the hardware and the operating system of the host. You might have to experiment to find the optimal value for your situation. The following general observations may be useful:
  • Most MID Server tasks require file handles to do their job.
    • Windows: On the Windows operating system, file handles are available in a fixed quantity. If you configure too many MID Server threads on a Windows host, the MID Server can consume all the file handles before approaching maximum CPU usage. This situation appears as an Out of file handles error in the MID Server log and indicates that the MID Server is trying to use too many threads.
    • UNIX and Linux: UNIX and Linux hosts have a much different scheme for allocating file handles. Generally, you can increase MID Server thread use on these operating systems until the CPU of the host is overloaded. See your OS documentation for monitoring CPU usage.
  • Each thread on the MID Server requires some memory. Exactly how much memory varies considerably from task to task and depends on the equipment being discovered. To increase the number of threads, you might have to increase the amount of memory that Java uses. If you configure insufficient memory, an Out of memory error appears in the MID Server log.

Follow the steps below to change the config.XML file. Alternatively, use the threads.max connection parameter.


  1. Open the \agent\config.xml file using any text editor.
  2. Locate the following lines:
    <!-- MID Server Threads --><parameter name="threads.max" value="25"/>
  3. Edit the value. Keep in mind the cautions described above.
  4. Save the record.
  5. Restart the MID Server service.

ECC queue retry policy

Define retry policies for outbound Web Services that are executed via the ECC Queue table.

Retry policies specify a matching error condition for ECC Queue input records that are a result or response of an output queue record, the interval for retry, and the maximum number of retries. Because it matches on the input queue record, the retry policies only work when an input ECC Queue record is expected, and therefore requires that the outbound messages are queued on the ECC Queue table as well. Advanced matching criteria may be specified using script.

Retry activity

The retry activity records document each attempt to retry the output queue record.

When the current policy is being retried, the Status of the activity will indicate Retrying. When all retries are exhausted, e.g. the maximum number of retries have occurred and the output queue still failed, the Status field will indicate a Failed state. Otherwise, at anytime during the retry, if the request then becomes successful, it indicates Succeeded.

Figure 1. Queue Retry Activity

You may also display the current list of retry activities and their states by selecting the Queue Retry Activity module.

Figure 2. Queue Retry Activities

Retry policy example

This retry policy defines the matching criteria when an UnknownHostException response is received during a SOAPClient (outbound SOAP message invocation) call.

Figure 3. Default Queue Retry Policy

The policy will only match if the Agent, Topic, ECC Name(matches the Name field), and Source fields match that of an input ECC queue record. Additionally, the Condition and Condition script criteria will also have to match "State == error" and the error_string field contains the text

When these conditions are met, and an input record is matched, it will retry the originating output queue record after 15 seconds, and for a maximum of 3 times.