Iâ€™ve been working on a script to generate an informative message to users when they exceed quota thresholds on our file server. The features of the File Server Resource Manager (FSRM) provides a variety of useful variables that can be plugged into an automated email. However, we have found that itâ€™s often very useful to provide more information about the kind of files that a user is storing, something akin to the output of the very useful and free utility WinDirStat.
Iâ€™ve made progress on the script that generates the email. However, Iâ€™ve run into a snarl in trying to configure the quota notification to run the script. The script runs just fine from a command prompt, even from a command prompt running as the Local System account. But when I trigger an FSRM event that should drive the script, I get an error in the Application Log:
Log Name: Application
Event ID: 8197
File Server Resource Manager Service error: Unexpected error.
Running command line action.
Quota limit reached.
Processing File Server Resource Manager event
Action type: Command Action
Account: NT AUTHORITY\LocalSystem
Executable path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Arguments: C:\local\secure\notify-test.ps1 -path [Quota Path] -email [Source Io Owner Email]
Quota path: K:\homes1\g\gcd
Threshold percent: 100
Error: AuthzInitializeContextFromSid, 0x80070005, Access is denied.
After spending hours searching online, I finally stumbled on a couple posts on the TechNet Forums. The first one described a problem very similar to mine, in which the poster worked around the issue by using a local admin account, rather than a domain account thatâ€™s a member of the Administrators group.
One of the responses to this post included instructions for modifying the ACLs on the FSRM XML data files. The first step is to use psexec to launch a command prompt as the Local System account. I didnâ€™t feel like mangling the ACLs on the FSRM on the production file server. I did like the reminder of psexecâ€™s capabilities.
I ran psexec -i -s and then ran my dirquota quota modify command as Local System. And when I triggered a quota event, my script fired successfully.
I will want to confirm with Microsoft Premier Support that modifying the ACLs is a safe operation before I do so, but at least I have a work-around until then.