File Server Resource Manager Service error: Unexpected error.
Operation:
Running command line action.
Quota limit reached.
Processing File Server Resource Manager event
Context:
Action type: Command Action
Action name: Command Action0
Account: NT AUTHORITY\LocalService
Executable path: C:\batch\fs_warning.vbs
Arguments:
Working directory: C:\batch\
Monitor command: FALSE
Log result: TRUE
Kill timeout: 0
Quota path: D:\student
Error-specific details:
Error: CreateProcess, 0x800700c1, is not a valid Win32 application.
The error for the email failure is the same eventid but the action is Email
Action, etc.
Does anyone have any ideas about why this is happening? The solutions I've
found on the Web ALL have to do with email, nothing about commands failing
in the same way. BTW, the vbs script runs fine when invoked separately,
just like the test email does. The email problem solution points to
authentication issues, but what about the command failure?
Thanks,
Geoff
There are two issues here.
1) You are running the command as LOCAL SERVICE. You will need to make sure that account has
read access to the command you are trying to run. Also, it will need write access to any files
you want to write to. Note: If you give LOCAL SERVICE or BUILTIN\Users *write* access to the
command *file* or *directory*, you will get an error saying "The specified path is insecure" and
Event ID 12300 in Application Event Log. These accounts shouldn't need write access to the
command or its directory. You can configure the command to run as NETWORK SERVICE or SYSTEM, but
don't use SYSTEM unless you really need to. I.e., don't just use it as an easy substitute for
setting the correct file permissions.
2) To get the VBS script to work, set up the command as follows:
Command: C:\WINDOWS\system32\cscript.exe
Command arguments: //nologo C:\admin\notify.vbs "Arg with space" [Quota Path] LastArg
Working directory: C:\admin
For a BAT file, use this:
Command: C:\WINDOWS\system32\cmd.exe
Command arguments: /c C:\admin\notify.bat "Arg with space" [Quota Path] LastArg
Working directory: C:\admin
In both of the above cases, I was able to get "quoted arguments" and [FSRM Variables] to work as
arguments to the scripts. To see a list of FSRM variables, run the following command:
dirquota notification /?
-Francis
I don't like only having the message popup that access is denied. I'm
guessing this is the standard built-in Windows error message generated when
one does not have permission to write to a folder. What I wanted was a more
specific explanation to the user about why they were denied. Since (if my
assumption about the error is true) I can't modify what error is generated
when a user tries to save disallowed files to the folder, I wanted to have
an additional message generated for the.
The vbs was a popup that tells them they are not allowed to save executables
to the folder. I don't know if it runs but stays on the server so the user
will not see it on the local computer or what. If so, there is probably a
way to make it display for the user on their computer, I haven't
investigated this yet.
The batch file option works, it's simply a NET SEND %username% <Warning
message>.
Any ideas of a better way to provide more information to the user about why
they can't do what they're trying to do? (Email is not an option, I'm in a
school environment)
Thanks,
Geoff
"Francis Favorini" <francis....@NOSPAMduke.edu> wrote in message
news:uq%23TJLa4...@TK2MSFTNGP05.phx.gbl...
Bingo. The command runs on the server.
>The batch file option works, it's simply a NET SEND %username% <Warning
>message>.
Barring email, this is the only thing I can think of that will work "out of
the box." I suppose you could use instant messaging (IM), but you'd need to
have an IM client installed on all the machines.
You could also try PsExec from http://www.sysinternals.com to remotely run
your VBS file. You'd use the -i switch to "Run the program so that it
interacts with the desktop on the remote system". Note, there are security
issues with this. You'd need to figure out what credentials to use to run the
remote process under. I think it uses LOCAL SERVICE by default. This would
probably work, but I haven't tried it. Don't use SYSTEM, which could be a
disaster if there are any bugs in your code. Be sure you understand the
implications of this method if you use it.
-Francis
P.S. Sorry about the ugly wrapping in my first post. I was trying to insure
the commands didn't wrap. Oh well.
Geoff
"Francis Favorini" <francis....@NOSPAMduke.edu> wrote in message
news:%23bWMS$a4GHA...@TK2MSFTNGP04.phx.gbl...