System-Level script not performing all functions

[BrentHedden]

I've got a "system-level" script that is scheduled to run at a certain time each day.

The script starts running OK with copying files and the such, but when it comes to the following line -

"C:Program FilesFileMakerFileMaker Pro 10FileMaker Pro.exe " "D:FMSnapshotsDaily SnapshotsCompressionCompress.fp7"

(which should open up the Compress.fp7 file), it never executes, and after about 10 seconds aborts. Which FMS then sends me an email stating error running the script "returned non-zero status -1" (anyone got info on this error??)

The script file is just a basic Windows batch files that runs all command lines just fine when I execute it under Windows or the command line.

I even modified the batch file to include just the above command, but it gave the same results. I tried running a different program under the same conditions, but still no go.

I'm presuming this isn't a problem that is just isolated to Server 10? Can we not execute other programs using the script scheduler?

[Steven H. Blackwell]

What privileges does the batch file have?

Steven

[BrentHedden]

I'm presuming that you mean security privileges on the file itself -

For Administrators, it's full access

For Users, it's Read & Execute

These are the standard Windows permissions when a file gets created.

I have Admin privileges, and the batch runs fine if I execute it under the command line or windows.

Unless FMS is running the file as a 'regular' user, and Users need to have full privileges, it wouldn't make any sense.

[Steven H. Blackwell]

No, when the batch file runs, it has to run under some levl of privilege. Does that level of privilege allow the actions you want. FileMaker Server runs as local system, and that may or may not be sufficient.

Steven

[BrentHedden]

Ok - makes sense. But the line in the batch file that's not firing is simply opening up a FileMaker file on the local machine (the file is not hosted). Even regular joe-blow users have privileges to do that.

On a related item, I noticed that anything the script is running is hidden in the background. Anyway to change that behavior?

[Wim Decorte]

What's the logic behind trying to make FMP open that file on the FMS machine??

The batch file when executed through the FMS scheduler runs in the security bubble of the account configured for the FMS service ("local system"). That's a headless account with no UI and you are trying to launch FMP which needs its UI to function. Won't ever work. And if you got it to work you'd end up with FMP running in memory but with no UI so if an error occurs you wouldn't be able to get to it except for killing the process which will very likely corrupt your file.

So what is it you are trying to achieve?

[BrentHedden]

The logic is fairly simple. Its meant to run scripts that can't be run otherwise because of web compatibility. That's the boulder of using FMS schedules.

We have a drone computer that uses a scheduler plugin to automate this now, but I was wanting to eliminate this extra piece of hardware.

I know it's suggested that one shouldn't run the client and server software on the same machine, but it's never really been explained to me exactly WHY that's a bad idea.

Thanks for the explanation of why the UI wouldn't come up. I figured it had something to do with accounts.

FYI - I did find a way to have FMP fire up - it involves using Windows schedules, and a simple batch (script) file that runs said schedule immediately. So I'm scheduling a schedule.

[Wim Decorte]

It can be done but for stability and security you're better off with your drone or robot machine.

For best security a server should run with nobody logged on. So that it is totally headless. That's why server apps are services so they run in the background without UI or active user account. FMP is a UI thing and needs a user to be logged in. You *can* run FMP in a non-UI state but it was not designed for that so sooner or later something will happen where FMP wants to draw its UI and it will fail, freezing the app's process. The only way out of that is to kill that process (and pray that whoever does that knows what they're doing).

Also your FMP on FMS might nog have the correct file references and may try to read the hosted files directly from the hard disk instead of through FMS and that will corrupt your files in the long run.

In short the reason why it's not recommended is not that it is not technologically possible, it's because it increases the risk of vulnerabilities and instability. And a good FMS deployment is all about safeguarding the data and lowering the risks as much as possible.