MID Server fails to restart after Yokohama upgrade causing NoClassDefFoundError and MID Server Down - Known Error

MID Server fails to restart after Yokohama upgrade causing NoClassDefFoundError and MID Server Down Description When upgrading from pre-Yokohama to Yokohama (any version below Yokohama Patch 6), MID Servers may fail to restart and remain in a DOWN state. If a MID Server upgrade fails, it typically attempts to restore to its previous version. However, the automatic restore process leaves behind newer-version JAR files, which can reference classes that are not present in the older release and result in runtime errors like NoClassDefFoundError. This affects the features and integrations that rely on that MID Server.

Affected Upgrade Path

Any upgrade from pre-Yokohama release to any Yokohama version below Patch 6 .

Root Cause

During the upgrade, the installer:

- Takes a backup of the existing MID Server folders.

- Copies new files from the upgrade package into the original folders.

If the upgrade fails after the backup is complete, the restore process may only copy the backup files over the existing folder, rather than removing the new files first. This can leave behind JAR files from the newer version that do not belong in the restored version, causing incompatibilities.

Note: Upon further investigation, the upgrade failures were found to be caused by permission misconfigurations during the Mid Server installation. Going forward, please follow the ServiceNow documentation instructions carefully when installing the Mid Server.

Steps to Reproduce

Create a Mid server on Xandau instance Lock some files in the folder using the below shell command $fileStream1 = [System.IO.File]::Open("C:\ServiceNow MID Server test_mid_upgrade_x_y\agent\lib\asia_bnet.xml", [System.IO.FileMode]::Open, [System.IO.FileAccess]::ReadWrite, [System.IO.FileShare]::None) Upgrade the instance to any affected Yokohama patch versions Expected : MidServer should be either upgraded successfully without any issues or mid server files should be reverted to the previous version if mid server upgrade fails.

Actual : MidServer upgrade fails with the following error in the agent log:

2025-06-18T10:30:51.727+0100 ERROR (WrapperStartStopAppMain) [Main:107] Error encountered during MID server execution java.lang. NoClassDefFoundError : com/snc/automation_common/integration/creds/ IAuthGenerator at com.service_now.mid.creds.provider.AuthGeneratorModule.configure(AuthGeneratorModule.java:15)

Workaround There is no simple workaround for this problem, but the issue has been resolved. Please upgrade to a version that has a permanent fix by reviewing the Fixed In section at the bottom of the KB. If you are unable to upgrade to a fixed version at this time, please follow the instructions below before the instance is upgraded to Yokohama affected versions to avoid the issue.

Note: The upgrade failures were due to a misconfiguration during the MidServer installation. We recommend checking whether any Windows Mid Servers on the instance are misconfigured with respect to permissions by following the instructions in Step 1 below.

Workaround:

Check if any Windows Mid Servers have been misconfigured regarding permissions during installation on the instance. Run the attached script( Check_InstanceHasMidSrvsWithMisconfiguredPermissions.txt ) as a background script. Check for the ' hasAnyWinMidSrvsUp ' variable in the output. If it is true, follow the further steps. Otherwise, you can skip the further steps. Go to ecc_queue list Apply the below filters: Agent = mid.server. Topic = JavascriptProbe Queue = input State = ready Open the record that has been created by running the above script Check the Payload field to identify any misconfigurations in the midserver and see how to correct it. Please see the instructions below on how to check the payload. Payload Format:

The payload contains a structured validation format, as shown below. Here are example scenarios, each with their expected payload outputs and the steps needed to address permission misconfiguration issues or indicates when no action is required.

Scenario

Output in the Payload XML field

If MID Server is configured with Local System User, no action is required

=== MID SERVER PERMISSIONS VALIDATION ===

=== VALIDATION RESULTS ===

Mid Server User: LocalSystem

1. LocalSystem: YES

2. Administrator User: NO

3. Start/Stop Permissions to the user on service: NO

Folder Permissions: YES

*** [ No action required ] - All permissions validated successfully ***

=== MID SERVER PERMISSIONS VALIDATION COMPLETED ===

If MID Server is configured with Administrator User, no action is required

=== MID SERVER PERMISSIONS VALIDATION ===

=== VALIDATION RESULTS ===

Mid Server User: DOMAIN\Administrator

1. LocalSystem: NO

2. Administrator User: YES

3. Start/Stop Permissions to the user on service: NO

Folder Permissions: YES

*** [ No action required ] - All permissions validated successfully ***

=== MID SERVER PERMISSIONS VALIDATION COMPLETED ===

If MID Server is configured with Regular User with Proper Permissions, no action is required

=== MID SERVER PERMISSIONS VALIDATION ===

Checking folder permissions for user: DOMAIN\midservice on path: C:\ServiceNow\MID Server\agent

=== VALIDATION RESULTS ===

Mid Server User: DOMAIN\midservice

1. LocalSystem: NO

2. Administrator User: NO

3. Start/Stop Permissions to the user on service: YES

Folder Permissions: YES

*** [ No action required] - All permissions validated successfully ***

=== MID SERVER PERMISSIONS VALIDATION COMPLETED ===

If MID Server is configured with Regular User with Missing Permissions (BAD)

=== MID SERVER PERMISSIONS VALIDATION ===

Checking folder permissions for user: DOMAIN\regularuser on path: C:\ServiceNow\MID Server\agent

=== VALIDATION RESULTS ===

Mid Server User: DOMAIN\regularuser

1. LocalSystem: NO

2. Administrator User: NO

3. Start/Stop Permissions to the user on service: NO

Failed to check folder permissions with icacls

Folder Permissions: NO

*** [ Action required ] - Permission issues found ***

- User needs LocalSystem OR Administrator OR Start/Stop permissions

- Follow KB1116916 to resolve user permission issues

- Service user needs Full Control on MID Server directory

- Follow KB1116916 to resolve user permission issues

=== MID SERVER PERMISSIONS VALIDATION COMPLETED ===

If the payload contains ' [No action required] ', no further action is needed at this time. However, if the issue persists after the Y upgrade for any other reason, please submit a case through ServiceNow. After resolving the permission issues, the issue should not occur once the instance is upgraded to the affected Yokohama versions. If the problem still persists, please submit a case with ServiceNow. FAQ’s :

Q: Will this affect both non-prod instances, prod instances?

A: Both production and sub-production instances are affected.

Q: How to check if the MID Server has misconfigured permissions on an instance?

A: Follow the first step under the workaround to check if the MID Server has any permissions misconfigurations.

Q: Does the issue occur if the instance upgrade is within the X family?

A: No, the issue doesn't occur if the instance upgrade is within the X or W family. It occurs only after upgrading from versions prior to Yokohama to any Yokohama version below Patch 6.

Q: Will this issue affect Linux MID Servers? If so, is there a workaround?

A: Yes, Linux MID Servers are also affected by this issue. There is no workaround. Please submit a case with ServiceNow regarding the issue on your Linux MID Server. Depending on the root cause, different steps may be needed to restore the MID Server to its previous state .