Export Script & MID Server Oddity: File Move Works, ECC Queue Doesn't Update!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-13-2025 09:52 AM - edited 05-16-2025 09:29 AM
Hi ServiceNow Community,
I'm encountering a very peculiar issue with a post-export script in my scheduled data export, and I'm hoping someone can shed some light on it.
Here's the scenario:
- We configured a scheduled data export with a post-export script.
- The post-export script's sole purpose is to move the exported file from the MID Server to a shared network location using a PowerShell command (move-item).
- The file is being moved successfully! I've confirmed this on the destination network share.
However, here's the problem:
- When I examine the ECC queue record related to this post-export script execution, the state field shows "Error".
- Digging into the ECC queue payload, I find no actual error messages in the <stderr> element. In fact, the state within the payload XML is "ready" (which seems incorrect).
It's as if the MID Server successfully executes the PowerShell command but then fails to update the ECC queue record's state correctly.
Here's a version of my post-export script:
var ecc = new GlideRecord("ecc_queue"); ecc.initialize(); ecc.agent = "mid.server.my-mid-server"; ecc.topic = "Command"; ecc.name = 'powershell move-item -Path "path\\to\\my\\file.csv" -Destination "\\\\network\\share\\destination"; Write-Host "File moved"'; ecc.queue = "output"; ecc.state = "ready"; ecc.insert();
I've already checked:
- MID Server permissions to the source and destination.
- Network connectivity.
- PowerShell execution policy.
- MID Server logs (which show the command being executed, but lack details on PowerShell's exit code or any errors).
I'm at a loss to explain this behavior. It seems to be working, but the persistent "Error" state makes me uneasy. I'd really appreciate any insights or suggestions on how to troubleshoot this further or ensure the ECC queue record accurately reflects the success of the file move.
Has anyone else encountered this type of discrepancy between successful command execution and the ECC queue's reported state? Any help would be greatly appreciated!
Thanks in advance!