Interpreting MID Server user debugging output

  • Release version: Zurich
  • Updated July 31, 2025
  • 4 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 Interpreting MID Server user debugging output

    This guidance explains how ServiceNow customers can enable and interpret debugging output related to MID Server user connectivity issues. Debugging output from the system log is available in two formats—summary and detailed—and must be enabled manually by running a method on the instance. These outputs help identify authentication, authorization, network, and configuration problems affecting MID Server user accounts.

    Show full answer Show less

    Available Output Formats

    • Summary View: Provides a quick count of issue conditions without naming specific users or MID Servers, useful for an overview of problem scope.
    • Detailed View: Displays specific information about users, their roles, MID Server associations, and login activity, enabling precise troubleshooting.

    Key Debugging Scenarios

    • Authentication Failures: Indicated by messages showing users with the midserver role failing to authenticate, often linked to incorrect passwords or down MID Servers.
    • Authorization Failures: Occur when users lack required roles. Detailed logs specify which roles are missing via event records, enabling targeted role reassignment.
    • Network Issues: Identified when users associated with down MID Servers or users with the midserver role but no MID Server association have no login attempts during the reporting period, suggesting connectivity problems.
    • Configuration Issues: Highlight users with the midserver role who are not associated with any MID Server or have inappropriate role assignments, indicating potential misconfiguration.

    MID Server ID Mapping

    The debugging output includes a mapping of all down MID Servers to their associated user accounts by MID Server sysid, covering users whether or not they are currently linked to a MID Server. This mapping helps identify relationships between users and problematic MID Servers.

    Practical Application for Customers

    By enabling and reviewing these debugging outputs, ServiceNow customers can:

    • Quickly identify whether MID Server user connectivity issues stem from authentication, authorization, network, or configuration problems.
    • Understand which users and MID Servers are affected, facilitating targeted remediation.
    • Use the detailed logs to pinpoint missing roles or misconfigurations in user accounts.
    • Adjust sampling periods during troubleshooting to match MID Server heartbeat intervals for more granular monitoring.

    This structured approach to interpreting MID Server user debugging output empowers customers to efficiently diagnose and resolve connectivity issues, ensuring reliable MID Server operations within their ServiceNow environment.

    Debugging output from the system log is available in either a summary or detailed view for MID Server user issues, but must be enabled manually.

    To enable debugging and display all connectivity issues in either of the available formats, you must run a method manually on your instance. For instructions on enabling debugging, see Test remediation efforts for MID Server user connectivity issues. For information about each error condition and how records are created in the MID Server Issue [ecc_agent_issue] table, see MID Server user connectivity issues.

    Available formats

    You can configure the instance to generate a simple summary of the issue or a detailed output that identifies users and MID Servers. Summaries provide a quick look at the issue conditions, by count, while the detailed view allows you to examine roles, MID Server associations, and login activity by named users.

    In this summary example of an authorization issue, the instance evaluates each condition and indicates how many users met that condition. You can see that a MID Server is down and that one of two users configured for a MID Server failed authorization. Because this is a summary, neither the MID Server nor the users are named.
    Figure 1. Sample summary debug output
    Sample summary debug output

    Authentication failure

    When a MID Server user cannot authenticate on the instance, the system displays these error messages in the detailed output:
    • Login authentication failure for User <user name> associated with 1 down MID Server. Check password on MID server.
    • Login authentication failure for User <user name> associated with <n> down MID Servers. Check password on MID servers.
    • Login authentication failure for User <user name> with mid_server role not associated with a MID Server.

    In this example, three users with the mid_server role, midserver2, local-midserver, and ardis.maison, failed to authenticate. Two of these users were configured for MID Servers that were Down, and the other user was not configured for any MID Servers. Each of these users has an authentication failure and is named in the appropriate error message.

    Figure 2. Detailed debugging log for authentication failure
    Detailed debugging log for authentication failure

    MID Server ID map

    The debugging output lists all MID Servers that are marked as Down and maps them to their user accounts by the MID Server sys_id. This map includes all user accounts that have the mid_server role, whether or not they are associated with a MID Server. If there are no Down MID Servers, the map is not displayed in the debugging output.

    The map is presented in three sections:
    • User accounts not associated with any MID Servers.
    • User accounts associated with Down MID Servers, identified by their sys_id.
    • The sys_id of each Down MID Server, identified by name.
    Figure 3. MID Server ID map
    MID Server ID map

    Authorization failure

    If a user is missing any of the required roles, the instance generates these authorization failure messages:
    • Login authorization failure for User <user name> associated with 1 down MID Server. Re-assign mid_server role to grant all required roles.
    • Login authorization failure for User <user name> associated with <n> down MID Servers. Re-assign mid_server role to grant all required roles.
    • Login authorization failure for User <user name> with mid_server role not associated with a MID Server.

    In this example, three users with the mid_server role, midserver2, local-midserver, and ardis.maison have failed authorization. One user is not associated with any MID Server, but the other two users are. The system has logged an authorization failure, indicating that the user is missing at least one critical role. To see what roles are missing, look at the comma separated list in the Parm2 field in the login.authorization.failed event record. This record is the most recent login attempt in the Event [sysevent] table for the user account within the reporting period.

    Figure 4. Detailed debugging log for authorization failure
    Detailed debugging log

    Network issues

    Network issues may exist for these users who are associated with MID Servers, but who have not attempted to log in during the reporting period:
    • User <user name> is associated with 1 down MID Server. No login attempts within reporting period.
    • User <user name> is associated with <n> down MID Servers. No login attempts within reporting period.

    Network issues may also exist for these users who are NOT associated with MID Servers, and who have not attempted to log in during the reporting period: User <user name> with mid_server role is not associated with a MID Server. No login attempts within reporting period.

    In this example, no login attempts have been detected for midserver2, local-midserver, and ardis.maison, all of whom have the mid_server role. Two of those users are associated with MID Servers that are marked Down. The other user is not associated with any MID Server. None of these users has attempted to log in to the system within the configured reporting interval. The system assumes that these users would make an attempt to log in unless network issues prevented them from doing so.
    Note:
    By default, the sampling period is 4 hours. However, during debugging or remediation, the sampling period can be reset to a value that matches the MID Server heartbeat interval of 5 minutes, or greater.
    Figure 5. Detailed debugging log for network connection issues
    Detailed debugging log

    Configuration issues

    Any of the following messages can indicate a user configuration issue:
    • Login authentication failure for User <user name> with mid_server role not associated with a MID Server.
    • Login authorization failure for User <user name> with mid_server role not associated with a MID Server.
    • User <user name> with mid_server role successfully connected but not associated with a MID Server. The mid-server role should be reserved for MID Server use only.
    • User <user name> with mid_server role is not associated with a MID Server. No login attempts within reporting period.
    In this example, a user with the mid_server role has logged in successfully within the configured sampling interval. However, this user is not configured for a MID Server and might have the role in error.
    Figure 6. Detailed debugging log for MID Server user account login
    Detailed debugging log for MID Server user account login