I have VBScripts that copy back up files across the network to a different computer. I cannot run them as a system script from Server either, I have to use an OS level task scheduler to run them on a schedule.
When I reported this as a bug many versions ago, I was told that server scheduled scripts could not reference locations external to the server's local drives.
Hi Phil, thanks for your reply.
I 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.
As a work around (although it still doesn't solve the problem with FMServer not running locally authenticated server side scripts), and as Phil has said, you can get the above working by running the system level script from Windows task scheduler instead of FMServer... (although it doesn't then work in tandem with a FMScript which is minor 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.:@echo off:VariablesSET serverPath=\\server\share\SET inbox=C:\Program Files\FileMaker\FileMaker Server\Data\Documents\IMPACTUK_GRANTPAYMENTS\inboxSET sent=C:\Program Files\FileMaker\FileMaker Server\Data\Documents\IMPACTUK_GRANTPAYMENTS\sentif exist "%inbox%\*.csv" (PUSHD "%serverPath%"FOR /F "delims=|" %%I IN ('DIR "%inbox%\*.csv" /B /O:D') DO COPY "%inbox%\%%I" & MOVE "%inbox%\%%I" "%sent%\"POPD)ExitNope, 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.
So my big question still is....
Can anyone else run a simple .bat file (e.g. echo test) as a system level script on a Windows 2013 Server with FMS13 with a locally authenticated account?
My current experience is that this causes a result of:
and an error message of:
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 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.