--- sourceDocument: Brazil ServiceNow AI Platform Capabilities sourceDocumentLink: https://www.servicenow.com/docs/r/servicenow-platform Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil ServiceNow AI Platform Capabilities ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # Active MID Server post-cloning credential issues # Active MID Server post-cloning credential issues {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 Active MID Server post-cloning credential issues After cloning a ServiceNow instance, MID Server credentials can become mismatched because the MID Server \[eccagent\] table is not copied, while the User \[sysuser\] table is. This can cause MID Servers to go down on the target instance due to invalid credentials. The system automatically detects and notifies you of these credential issues to help maintain MID Server availability and functionality. Show full answer Show less ## Key Features * **Detection and Notification:** The system identifies MID Servers that are down possibly due to bad credentials following an instance clone and stores these issues in the MID Server Issue \[eccagentissue\] table. * **MID Server Issue Table:** This table records active post-cloning credential issues, showing the MID Server state, evaluation times, and issue source (notably *InstanceClone* for cloning-related problems). Issues are automatically removed after 30 days if not detected again. * **Post-cloning Cleanup Script and Scheduled Jobs:** A cleanup script runs after cloning to schedule jobs that log MID Servers in the Down state caused by potential credential mismatches. These jobs run twice after cloning (at 15 and 75 minutes) and focus only on MID Servers existing before the clone. * **Business Rule for Resolution Monitoring:** The "Check for bad MID credential after clone" business rule monitors MID Servers transitioning from Down to Up. It updates the related issue records to Resolved when a MID Server recovers. ## Resolving MID Server Credential Issues The system provides clear error messages in the MID Server Issue table identifying the affected MID Server user. To resolve issues: * Verify and compare the credentials of the named user with what the MID Server expects. * If credentials are incorrect, update them accordingly and then recheck the MID Server status. * If credentials are correct but the MID Server remains down, further investigation and consultation of the Knowledge Base is recommended. This automated detection and notification process helps ServiceNow customers efficiently identify and fix MID Server credential issues after cloning, ensuring smoother transitions and ongoing MID Server operations. The system provides automatic processes to detect and notify you of possible MID Server credential issues after instance cloning. During an instance clone, the MID Server \[ecc_agent\] table is not copied from the source instance, but the User \[sys_user\] table is copied. As a result, the source MID Server user credentials copied into the target instance might not match those used by the existing set of MID Servers used by the target. Bad credentials can cause those MID Servers to be down for the target instance. Processes on the instance notify you if a MID Server is down from suspected bad credentials following an instance clone. ## Table for post-cloning credential issues The MID Server Issue \[ecc_agent_issue\] table stores active MID Server issues after an instance clone. Records in this table show a MID Server's current state, evaluation times, and the Issue source. For cases in which a MID Server for a cloned instance is down because of possible bad credentials, the Issue source is InstanceClone. Data from the MID Server Issue \[ecc_agent_issue\] table are displayed in a related list on a MID Server record. Records in this table are removed if they have not been detected for 30 days. Ongoing issues reappear as they occur. ## Post-cloning cleanup script and scheduled jobs A cleanup script called Bad MID Server credentials after clone runs on the target instance after cloning and calls a script include called BadMIDCredentialAfterClone. This script include schedules the execution of the following jobs on the Schedule Item \[sys_trigger\] table: * BadMIDCredentialAfterClone-1: Runs 15 minutes after clone execution. * BadMIDCredentialAfterClone-2: Runs 75 minutes after clone execution. {#mid-post-clone-issue-resolution__ul_dgl_bzt_3y}These jobs log to the MID Server Issue \[ecc_agent_issue\] table any MID Servers that existed on the target instance prior to the clone that are in the Down state. These MID Servers are not ready for normal processing and might be down due to invalid credentials resulting from the cloning process. The state of MID Servers added to the target instance after the clone is not evaluated. Note: The [MID Server log](https://www.servicenow.com/docs/9ziUp3Kqx2jdRlmVhWQriA#manage-ecc-queue-content "The ECC Queue allows you to create ECC Queue messages, access MID Server log entries, and retrieve statistics from an individual MID Server record.") shows that the MID Server user associated with the target instance could not be authenticated or was missing the proper role. ## Business rule that checks for bad credentials The Check for bad MID credential after clone business rule monitors the MID Server \[ecc_agent\] table for MID Servers that are transitioning from Down to Up. If the business rule finds a MID Server making that transition, the rule attempts to find a matching MID Server in the MID Server Issue \[ecc_agent_issue\] table that has an issue source of InstanceClone and a state other than Resolved. If a match is found, the business rule updates the state of the MID Server in the \[ecc_agent_issue\] table to Resolved. ## Resolving MID Server issues The error message in the MID Server Issue \[ecc_agent_issue\] table names the affected MID Server user. This message appears each time the business rule runs and finds a MID Server that is down from suspected bad credentials:MID Server not operational (status: Down), possibly due to recent clone. Verify credentials for logged in User 'local-midserver'. Attempt to resolve the issue first by comparing the user's credentials with the credentials that the affected MID Server is expecting. If the credentials are incorrect, fix the problem and check the MID Server status again. If the credentials are correct, but the MID Server remains down, check the [Knowledge Base](https://support.servicenow.com/nav_to.do?uri=/kb_view.do?sysparm_article=KB0597571) for other possible causes.