How to fix FSRM script execution errors ???

Advait Mohammad 40 Reputation points
2026-09-08T04:09:34.0433333+00:00

Hi

I’m trying to configure FSRM to run an anti‑ransomware script whenever a file screen violation occurs, but the command action fails with 0x80070002 (File Not Found). It looks like the script path or the service’s security context isn’t set correctly, preventing execution. I need help figuring out how to reconfigure script execution paths and adjust service permissions so the script runs reliably after a violation. Many thanks

Windows for business | Windows 365 Business
0 comments No comments

1 answer

Sort by: Oldest
  1. Chen Tran 12,770 Reputation points Independent Advisor
    2026-09-08T05:01:29.79+00:00

    Hello Mohammad,

    Thank you for posting question on Microsoft Windows Forum!

    Based on the issue description as well as the provided error code. Well! The 0x80070002 (File Not Found) error in FSRM Command Actions might indicate that FSRM does not know how to execute it. FSRM cannot natively execute .ps1, .bat, or .vbs files directly from the "Command" field. It requires a direct path to an executable (.exe), and the security context requires strict pathing and permissions.

    The suggestion here is to point FSRM to the PowerShell interpreter, not your script, and pass the script as an argument. FSRM also struggles with relative paths and environment variables, so absolute paths are mandatory. Executable command like this C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe (Do not use %SystemRoot% here; type the explicit drive letter). For Working Directory. Always specify the directory where the script resides. If you leave this blank, FSRM defaults to C:\Windows\System32, which can break relative paths inside your script.

    On the other hand, FSRM executes command actions under the Local System (SYSTEM) account by default. If your script is failing silently or throwing access denied errors under the hood, it is probably because SYSTEM lacks permissions. Right-click the folder hosting your script (e.g., C:\Scripts), go to Properties > Security, and ensure the SYSTEM account has Read & execute permissions. Also, since the script runs as SYSTEM, it has no concept of the logged-in administrator's mapped drives or network shares. If your script needs to write to a remote logging server or access a remote share, it will attempt to authenticate as the computer account (DOMAIN\ServerName$). You must grant the computer account permissions on the destination share, or rewrite the script to use explicit credentials.

    Hope the above information is helpful! If it is. Free feel to hit "Accepted" for benefitting others in community having the same query too.

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.