MID Server FileNameComplianceInSync Error

[Derek Jones]

We're facing a recurring issue on a MID server of ours that is proving to be quite challenging. Despite our efforts, we haven't been able to pinpoint the cause. The issue record has a source of FileNameComplianceInSync and the following short description:

Attachment file with sys_id: XXXX was not synchronized, as the file's absolute path is outside the target directory. Please rename the file appropriately. If deleting this file instead of renaming, please manually resolve this MID Server Issue record.

Of course, we searched for that sys_id in both the sys_attachment and looking in a number of the ECC tables but not found out anything, nor using SN Utils' search; The MID is fine otherwise, but we'd like to get rid of that error message all the same. 

Has anyone seen this error before and found a way to clear it? 

[Anmol8]

Hey Derek,

The error message you're encountering suggests that the MID server is trying to synchronize a file, but the file's path is outside the expected directory structure. This is triggering the "FileNameComplianceInSync" error. Here’s how you can approach the problem:

1. Check the MID Server's Configuration:
- Ensure that the MID server's file paths and target directories are correctly configured.
- Review the `mid.property` configurations, especially properties related to file synchronization and attachment handling, to ensure they align with your environment's requirements.
2. Investigate the Attachment Sys ID:
- Since you've already searched for the sys_id in `sys_attachment` and ECC tables without success, it might be helpful to search directly within the MID server's logs.
- Search for the sys_id in the MID server's logs to see if there are any clues about when and why the attachment was created or attempted to be synchronized.
3. Check ECC Queue for Related Records:
- Search the `ecc_queue` table for any records related to the attachment, using either the sys_id or related keywords.
- Look for any potential errors or warnings that might have been logged when the attachment was processed.
4. MID Server Log Files:
- Go to the MID server and check the log files directly (e.g., `agent0.log`, `wrapper.log`). Look for entries around the time the error was recorded to see if there are any more detailed error messages or stack traces that could point to the source of the issue.
5. Manual Clearance:
- If the file is no longer needed and cannot be found via the usual tables, you might need to manually clear the issue as the message suggests. This involves:
1. Marking the MID server issue record as "Resolved."
2. Confirming that no other related errors appear after clearing this one.
6. Evaluate MID Server Scripts:
- If there are custom scripts running on the MID server, review them to ensure they aren't inadvertently creating or processing files incorrectly.
7. Clear Cache and Retry:
- Sometimes issues like these can be due to stale data. Clear the MID server cache (`sys_cache_flush.do`) and restart the MID server.
Final Step:
If none of the above steps resolve the issue, consider:
- Opening a Support Ticket with ServiceNow**: If the error persists, it may be an edge case or bug that requires more in-depth investigation by ServiceNow's support team.

Thanks and Regards,

Anmol

[davidpiper]

I suspect it may well be this. We have had a few support cases recently.
PRB1797792  Clone are excluding attachments on MID Server Script files [ecc_agent_script_file], brea...

which in Xanadu leads to:

PRB1797811  MID Server Issue: Misleading FileNameComplianceInSync Attachment file errors, when ecc_a...

The sys_id is the one set in the ecc_agent_script_file record's script_attachment field. You won't find any record with the sys_id in sys_attachment, because it being missing is why you end up with that error.  So find the ecc_agent_script_file records with Use Attachment ticked, and see if they do have attachments.

[rachelconstanti]

@Derek Jones - we just upgraded our dev instance to Xanadu and received this message on our discovery mid server.

Look like it will be fixed in Yokohama.

Are you just manually resolving the issue?

Thank you,

Rachel

[chrisboylan]

I see the record in question - ADMELauncherWinRM.psm1 - has the Use Attachment checkbox checked.   That is causing it to look for the Attachment file with sys_id: e88f49a043032110c42154249ab8f24b.   This does not exist and the PRB1797811 article says the record uses the script action, not the attachment.   I simply unchecked the box and the script appeared.   This seems like it should end the issue.   Anyone see a problem with this?   The record was originally created in 2017.   Not sure when the attachment disappeared or if it ever had one, the script that showed up has been there since 2017 too,