Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Windows 2003 FSRM command options don't work

352 views
Skip to first unread message

Geoff Varney

unread,
Sep 26, 2006, 11:36:34 AM9/26/06
to
Hello,
I upgraded a test server from 2003 SP1 to 2003 R2 and have been testing the
File Server Resource Manager File Screening Management. I set up a file
screen to prevent saving executables and it works fine. However, if I
configure a COMMAND to run when the screen is triggered, it doesn't work.
This is identical to the problem I've read about where email notifications
fail, though the "test" message works. In fact, email notifications also
fail when triggered by a file screen in my case. But I am NOT using
Exchange for email, using IMail. The error that appears in the event log
is:
Source: SRMSVC
EventID: 8197

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

Francis Favorini

unread,
Sep 26, 2006, 3:34:28 PM9/26/06
to
In article <esAArHY...@TK2MSFTNGP06.phx.gbl>, geoff....@ridge.k12.wa.us says...

>I upgraded a test server from 2003 SP1 to 2003 R2 and have been testing the
>File Server Resource Manager File Screening Management. I set up a file
>screen to prevent saving executables and it works fine. However, if I
>configure a COMMAND to run when the screen is triggered, it doesn't work.
>[...]

>Account: NT AUTHORITY\LocalService
>
>Executable path: C:\batch\fs_warning.vbs
>
>Arguments:
>
>Working directory: C:\batch\

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

Geoff Varney

unread,
Sep 26, 2006, 4:30:15 PM9/26/06
to
Thanks, Francis. Your instructions definitely helped. I no longer see the
error, but in the case of the vbs, I don't get the result I wanted. The
batch file option does work. Let me explain what I'm after:

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...

Francis Favorini

unread,
Sep 26, 2006, 5:07:46 PM9/26/06
to
In article <#YRJDsa4...@TK2MSFTNGP04.phx.gbl>,
geoff....@NOSPAMridge.k12.wa.us says...

>I don't like only having the message popup that access is denied.
>[...]

>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.

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 Varney

unread,
Sep 26, 2006, 6:38:28 PM9/26/06
to
Thanks again. I have used PsExec for some things in the past. I'll
consider it and see if I can find an acceptable way to use it for this. Or
I'll use NET SEND, or I'll just live with it!

Geoff

"Francis Favorini" <francis....@NOSPAMduke.edu> wrote in message

news:%23bWMS$a4GHA...@TK2MSFTNGP04.phx.gbl...

0 new messages