I've tried a few things and think there's a problem with FMS13 using any account other than the default one... Here's why:
Here's my new batch script and i apologise for it's complexity:
So, if I run this without ticking the 'use a User account rather than the default account', it runs OK. (As does copying my .csv file from a local folder to another local folder.)
But if I run the above 'echo test' with a 'User Account' - and for this I've set up a brand new account in the administrator group called FMServer - then I get the utterly frustrating 'Aborted Unexpectedly' message:
Error 154 TF_FMS2 Schedule "Batch Again" aborted; "test.bat" could not be found or is invalid.
Again, given that this file:
1) Can be found
2) Is valid (as it runs without the user account selected)
means that the above is a very poorly constructed error message.
I have tried using both just username and computername/username as per the instructions for Windows in the server help. There also appears to be no 'Validate Account' option in the FMS13 admin panel as there was in previous versions. And FMS doesn't seem to be able to validate any account to run a system level script.
Can anyone else test this on a different instance? I think this needs to be fixed before I can troubleshoot my script for problems which seems to otherwise run fine.
I could reproduce it on Windows7 Home (not supported platform, installed for fun).
Windows security log said log on succeed.
Of cource the user is logging on now and able to see the script file, FMS's error 'not found' is nonsence.
And the user is in group Administrators, then has access full control.
I guess that the installed path (default) is in "Program Files" causes trouble since it is not prefered to use as data folder.
When I put a file or edit a file in the folder, everytime I got dialog to confirm it.
Hi, thanks for your reply and for testing this out....
When you say, 'you could reproduce it on Windows7', does that mean that you can reproduce the error? or that you can reproduce the scenario and the .bat runs ok for you?
As a work around (although it still doesn't solve the problem with FMServer not running locally authenticated server side scripts) you can get the batch file working by running the system level script from Windows task scheduler event... (although it doesn't then work in tandem with FMS which is pain)
However, for those needing to work with server/shares the change you will need to make is to PushD to change directory to the server/share first, otherwise you won't be able to make a the copy of the file as you can't use a UNC path in a scheduled script e.g.:
SET inbox=C:\Program Files\FileMaker\FileMaker Server\Data\Documents\IMPACTUK_GRANTPAYMENTS\inbox
SET sent=C:\Program Files\FileMaker\FileMaker Server\Data\Documents\IMPACTUK_GRANTPAYMENTS\sent
if exist "%inbox%\*.csv" (
FOR /F "delims=|" %%I IN ('DIR "%inbox%\*.csv" /B /O:D') DO COPY "%inbox%\%%I" & MOVE "%inbox%\%%I" "%sent%\"
Nope, I don't really understand the UNC bit either, but here's some references:
What the above script is doing, is just setting some variables, checking if any .csv files exist in the inbox, and if they do, copying the latest file (%%I) to the server/share. It then moves the file out of the inbox to the sent folder.
The PushD command essentially takes you to the server/share and sets it as your current working directory so you can copy the file there, otherwise the CMD process which is called via the Task Scheduler doesn't understand the serverPath reference.
I mean that the error occurred. Sorry I don't speak English then my wrote may be difficult to mean.
After the reply I tested adding the user to have full control on 'data' folder, but the result is same. FM server script aborted.
The user is in the Administrators group, so this should no matter.
But the file access is changed, the .bat file in data/script became edittable.(First time I saved it another place and move into there.)
I think the folder is under 'Program Files' then it has a bit deferent behaviour than usual folders.
Hi - thanks again for your reply and thanks for testing. Yes, I see the same behaviour as you. I think I will file this as a bug.
PS your English is far better than any other language I can speak!
TSGal has answered this question here:
Basically, to get a system level script running, you simply need to add .\ before the username on windows.
So the script now runs but doesn't copy to the server\share so I think I need to add a domain account to run the script by rather than a local user account. Or just leave it running divorced in Windows Task Scheduler which is now working.
I confirm that adding .\ before the username makes script to run.
But, it seems that the script is run as SYSTEM, not the specified user.
The script.bat is
ECHO test > C:\temp\fmscript.txt
and the created file's owner is 'SYSTEM'.
In Windows Security Event log, event iD 4672 twice at one schedule.
first account name the specified username,
second account SYSTEM
I guess this cause server\share unusable.
Tested on windows 7 pro, workgroup environment.